Setting server diagnostic levels in Exchange 2013

The ability to set diagnostics at different levels for the various components that function on an Exchange server has always existed. From Exchange 4.0 to Exchange 2003 you set diagnostic levels through the management console by selecting the component (for example, ActiveSync) and the level that you wanted to apply. Once a new level is set, Exchange complies by outputting more or less detail about its operations as events written into the Application Event Log. This mechanism worked well until Exchange 2007 appeared and administrators discovered that the new Exchange 2007 management console included no GUI to deal with diagnostics, meaning that they had to set diagnostic levels through EMS.

Microsoft addressed the problem in Exchange 2007 SP2 when they included the ability for EMC to set server diagnostics as properties of a server in addition to manipulation through PowerShell. The same behavior exists in Exchange 2010 but the transition from the old MMC-based console architecture to the browser-based Exchange Administration Center (EAC) in Exchange 2013 has resulted in the disappearance of the UI to manipulate server diagnostic levels. Or, possibly more correctly, the developers who created the new browser-based administration console simply ran out of time to include what might be considered to be a “nice to have” rather than “essential” feature. Frustratingly, this omission has not been addressed in any cumulative update since.

Another development for event logging in Exchange 2013 arose from work such as the rewrite of the Store into managed code and the introduction of modern public folders. A side effect of these projects is that a large number of previously well-known event logging categories have been either removed from Exchange 2013, replaced with a new logging category, or subsumed into yet another category. The upshot is that administrators who have created diagnostic scripts that depend on event logging categories to help them debug a problematic Exchange server have some work to do to review their code and potentially adjust calls to work with Exchange 2013.

The lack of UI to set server diagnostics means that we have returned to manipulating diagnostic levels through EMS. For example, to set the logging level to “High” for the operations performed through EAC (which still uses the old Control Panel name for diagnostic purposes), you type:

Set-EventLogLevel –Identity “MSExchange Control Panel\General” –Level High

Microsoft’s documentation on the available event logging categories is sparse to non-existent. However, there’s an easy way to retrieve a full set of current event logging categories by interrogating a server. To do this, use the Get-EventLogLevel cmdlet to return a list of the current diagnostic levels for a server. The list can also be used to verify that the correct settings are in place for each category. The cmdlet doesn’t support a filter function to allow you to specify that you only want details of event categories for the Store or transport, but as we want a full list, we can simply capture the output into a text file for easier examination. For example:

Get-EventLogLevel –Server ExServer1 > C:\Temp\EventLevels.txt

The list of event categories is roughly organized into areas of functionality such as Autodiscover, RBAC, replication, and so on. A little trial and error is therefore necessary to figure out exactly what is the best event category for which you should increase logging level when debugging a particular area of functionality.

As shown in the table below,  Exchange supports five levels of diagnostic logging based on the level assigned to events recorded by the application. Critical events and those assigned a level of zero are always written into the event log. Events with a higher level are captured if an elevated diagnostic level is chosen.

Level Description
Expert Highly verbose: Essentially Exchange documents everything it does
High Quite verbose: Exchange logs any event with a level of five or lower
Medium Fairly detailed: Exchange logs any event with a level of three or lower
Low Reasonable detail: Exchange logs any event with a level of one or lower
Lowest Only critical events or errors with a logging level of zero are captured; this is the default level used for most Exchange event categories.

Be careful about setting diagnostic levels to Medium or higher. Exchange is quite happy to provide a vast amount of diagnostic information by writing events into the Application Event Log, but you run the risk that you won’t be able to see the forest for the trees and some essential piece of information will be overlooked simply because so much data are available. To prevent the Application Event Log from being clogged up with an excessive number of events, make sure that you reset the diagnostic level to Lowest when you’ve completed troubleshooting the problem that caused you to elevate the level.

Change is wonderful (usually). I am sure that EAC will fill the gap over time. But for now, the more that I work with EAC, the more gaps I find. It’s a bit like Exchange 2000 all over again…

Follow Tony @12Knocksinna

About these ads
Posted in Email, Exchange 2013 | Tagged , , , , | 1 Comment

Exchange 2013 improves USG management through EAC and OWA

Exchange 2010 SP1 made a change to limit the ability to make changes to universal security groups (USGs) via the Exchange Management Console (EMC), which meant that administrators were no longer able to use EMC to amend USG membership, a side-effect of the introduction of support for a split permissions model. The problem was subsequently addressed in KB2487852 and administrators could once again use EMC to modify USG membership.

Exchange 2013 replaces EMC with the browser-based Exchange Administration Center (EAC), which builds off the Exchange Control Panel (ECP) used by Exchange 2010 for some administrative purposes and to set user options in Outlook Web App (OWA). Like many transitions, the switchover from EMC to EAC was bumpy in places. EAC has steadily improved as Microsoft has released cumulative updates, and it seems that some recent updates in Exchange 2013 CU6 have improved the ability to assign the ability to work with USGs to users who are not administrators.

As I documented in “Microsoft Exchange 2013 Inside Out: Mailbox and High Availability” (page 284-5), Exchange 2013 RTM would only allow users to create USGs through OWA if they were a member of the all-powerful Organization Management RBAC role group. Users who were members of the Recipient Management role group could create USGs through EAC, but a disconnection existed in the ability of the two role groups to interact with USGs through OWA and EAC.

Prompted by a recent question from a reader, I went back to look at the current situation as implemented in Exchange 2013 CU6 and found some improvements. The scenario that many are interested in involving giving permissions to help desk personnel to manage USGs without having to include those users in the Organization Management role group.

To test what can be done today, I created a role group called Help Desk Level 2 and assigned it the kind of management roles that I think you’d expect to find given to people who provide second-level support. The set of roles included the Security Group Creation and Membership role. As you’ll recall, an RBAC role is composed of a set of cmdlets and parameters that can be executed by users who are assigned the role through their membership of a role group.


By the way, if you’re at Exchange Connections in Las Vegas next week, be sure to check out the session on “Role Based Access Control and You” given by Bharghav Shukla (2:45pm on Wednesday). It’s just one of the in-depth technical sessions given by independent experts that you’ll get at Connections.

I then added some users to the role group. The next time the users log in and authenticate to Exchange, the RBAC evaluation that is part of this process will detect their membership of the Help Desk Level 2 role group and assign them the roles covered by the group. In effect, all of the cmdlets and parameters defined for each of the roles will then be available to the users. This is what happens when you start an EMS session with Exchange 2013 or Exchange Online and you see the message saying that command information is being got for the remote (PowerShell) session and that a certain number of commands have been loaded. Each one of those commands is described in a role assigned to the user.

An EMS session reports as it loads commands

An EMS session reports as it loads commands

The next step was to log into OWA using one of the user accounts that held the Security Group Creation and Membership role. OWA and EAC share the same “slab-based” user interface, which means that user interface components are only loaded if the user has the permission to interact with an object. For example, if your user does not hold the permission to work with public folders, you won’t see the public folders UI through EAC.


Through OWA options, I was able to create and edit USGs. The important caveat here is that you can only edit USGs if your account is listed as a group owner, presumably because USGs hold security principals that might be used to protect confidential information and you don’t want to create the potential for that information to be compromised by a change made by someone other than a group owner. The same behavior now extends across both EAC and OWA. It would be good if this fact was clearly called out in the TechNet article that documents the Security Group Creation and Management role as I can see how confusion might arise when a user who holds the role attempts to edit the membership of a USG that they don’t own.

However, there is a workaround. The Update-DistributionGroupMember cmdlet is used to update group membership of both USGs and (normal) mail-enabled groups. This cmdlet supports a BypassSecurityGroupManagerCheck switch that allows any user who holds the Security Group Creation and Management role through membership of a role group like Recipient Management to update the membership of a USG without being a group manager. Thus, it is possible to use this workaround in a scenario where you want to allow administrators to update USGs without having to add every administrator to the ownership of every group.

EAC command logging reveals how it runs Update-DistributionGroupMember

EAC command logging reveals how it runs Update-DistributionGroupMember

As can be verified with command logging, EAC never passes the BypassSecurityGroupManagerCheck switch when it calls the Update-DistributionGroupMember cmdlet. This is to ensure that the same behaviour exists across EAC and OWA, which is a good thing. It’s also good that some of the restrictions that existed in older versions of Exchange 2013 have now been addressed!

Follow Tony @12Knocksinna

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

Reporting delegate access to Exchange mailboxes

All current versions of Exchange 2013 (up to and including CU6) and Exchange Online (Office 365) contain a bug that can compromise the ability of companies to comply with discovery orders. The bug means that a user can remove items from a mailbox without copies being retained, even if the mailbox is under the control of a litigation or in-place hold. The good news is that the problem only appears with the Outlook Web App (OWA) client. It is not possible to exploit the retention hole in Outlook or any mobile client, including OWA for Devices.

Obviously, anything that affects compliance is a serious issue. No one wants to be in front of a judge and admit that their email system is incapable of retaining all of the items specified in a discovery action, which is exactly the purpose of the immutability features incorporated into Exchange 2010 and enhanced in Exchange 2013. Microsoft is working on a fix and this should appear in first in Exchange Online and then in Exchange 2013 CU7. No date is yet available for when this will happen.

In the interim, Microsoft suggested two workarounds in KB2996477. These are:

  • Put a hold on all users who are participating in delegated scenarios.
  • Disable OWA for users who have delegated access to their mailbox.

The first suggestion addresses the fact that the hole only appears when some form of delegation (non-owner access) is in place for the mailbox as this access is used to move or delete items from a mailbox without preservation of the copies of the deleted items within the Recoverable Items structure of the mailbox. It is this preservation that allows the apparently deleted items to be indexed by Exchange and therefore discoverable and accessible through administrator-initiated eDiscovery searches.

Placing a hold on everyone who is involved in some form of mailbox delegation (such as accessing a shared mailbox or the classic “manager-administrative assistant” scenario) ensures that items moved or deleted via the delegation are preserved and is therefore a solution. However, some practical difficulties face administrators who want to take this action.

The first challenge is to discover what users are accessing shared mailboxes. It’s possible that you already have a list of shared mailboxes and know who is using these mailboxes, but if not, you can run this code to create a quick list:

Get-Mailbox –RecipientTypeDetails ‘SharedMailbox’ | Get-MailboxPermission | where {$_.user.tostring() -ne "NT AUTHORITY\SELF" -and $_.IsInherited -eq $false} | Format-Table Identity, User, AccessRights –AutoSize

Identity                                       User                        AccessRights
--------                                       ----                        ------------ users/EMEA Help Desk (IT) CONTOSO\TRedmond            {FullAccess} users/EMEA Help Desk (IT) CONTOSO\Ito                 {FullAccess} users/APJ Help Desk       CONTOSO\TRedmond            {FullAccess} users/APJ Help Desk       CONTOSO\Ako                 {FullAccess} users/APJ Help Desk       CONTOSO\JChen               {FullAccess} users/Contoso PR queries  CONTOSO\TRedmond            {FullAccess} Queries        CONTOSO\TRedmond            {FullAccess} Queries        CONTOSO\Akers               {FullAccess}

However, shared mailbox delegation is the least likely route to exploit the bug. My judgment is that it is more likely that a user who seeks to mask his actions will use folder-level delegation. OWApermissionsUnderstanding who has access to individual folders in other mailboxes is a more difficult task, if only because administrators don’t usually know when users delegate access to folders in their mailboxes to other people. This is easily done with Outlook or OWA by editing the properties of a folder and assigning other users permissions such as “Publishing Editor” or “Editor”, both of which will allow delegates to remove items from the folder.

I did a brief search of the Internet to see if I could find anything that would report delegate access to mailboxes. Quite a number of scripts focus on calendar delegates, such as, but we’re really concerned with folders that hold mail items rather than calendar appointments and meetings.

Charting out what needs to be done is easy enough. Establish a collection of mailboxes, discover what folders exist in those mailboxes, and then check the access rights on the folders to find out whether delegates exist. You might come up with code like this:

Get-Mailbox  -RecipientTypeDetails ‘UserMailbox’ | Get-MailboxFolder –Recurse -MailFolderOnly | Get-MailboxFolderPermission | Where-Object {$_.AccessRights –notlike “Owner” –or $_.AccessRights –notlike “None”} | Format-Table Identity, FolderName, User, AccessRights –AutoSize

As evident by the pile of errors that you’ll see when you run the code against either Exchange 2013 or Exchange Online, a couple of problems exist with this approach. First, you don’t have the necessary access to list the contents of other user’s mailboxes. As TechNet reminds out about the Get-MailboxFolder cmdlet, it can only “retrieve folders for a specified mailbox when the mailbox owner runs the command.”

So, while you’ll see information like this for your own mailbox:

Identity                       FolderName User            AccessRights
--------                       ---------- ----            ------------
TRedmond:\Deleted Items\ProjX  ProjX      Deirdre Redmond {PublishingEditor}
TRedmond:\Travel               Travel     Deirdre Redmond {Reviewer}

Get-MailboxFolder is a dead end for our purpose, even if your account has been granted Full Access to those mailboxes or you run the script from the Administrator account. We have to look for a different way that allows an administrator to retrieve information about the folders in user mailboxes. Fortunately, Get-MailboxStatistics comes to the rescue because it reports folder names amongst other interesting statistical information about folder contents.

Playing around with Get-MailboxStatistics gives us a script that outputs details of any non-user permission applied to a mailbox folder. This should be sufficient to identify users who have delegate access to other mailboxes who can potentially exploit the bug. I have tested this code with both Exchange 2013 CU6 and Exchange Online.

$AllUsers = Get-Mailbox -RecipientTypeDetails 'UserMailbox' -ResultSize Unlimited

ForEach ($Alias in $AllUsers)
$Mailbox = "" + $Alias.Name
Write-Host "Getting folders for mailbox: " $Mailbox
$Folders = Get-MailboxFolderStatistics $Mailbox | % {$_.folderpath} | %                     {$_.replace(“/”,”\”)}

ForEach ($F in $Folders)
$FolderKey = $Mailbox + ":" + $F
$Permissions = Get-MailboxFolderPermission -identity $FolderKey -ErrorAction                 SilentlyContinue
$Permissions | Where-Object {$_.User -notlike "Default" -and $_.User -notlike               "Anonymous" -and $_.AccessRights -notlike "None" -and $_.AccessRights -notlike            "Owner" }| Format-Table $Mailbox, User, FolderName, AccessRights -AutoSize

The normal warning about downloading and running code from a web site applies here. Do not run this code on a production server without testing it first. You have been warned…  And do please take every opportunity to improve and enhance the code. For example, a more production-ready version would output details of the permissions to a CSV-format or other file to collect data that is more easily reviewed and subsequently processed.

Speed is the second problem with our PowerShell script. Like many other examples of scripts that you can find around the Internet, this code executes reasonably quickly for a small to medium organization but will run into horrible problems if you attempt to examine mailbox permissions across an organization that spans anything more than a few hundred mailboxes. So access and speed issues are areas of concern that have to be addressed.

Running this kind of intensive PowerShell processing in the background helps somewhat when you have large amounts of data to process. MVP Serkan Varoglu explains how to do this in two posts. Part 1 explains the basics and part 2 provides some more Exchange-specific information.

But a better and more functional solution might be found with Exchange Web Services (EWS), which is the preferred programming API to develop solutions against the contents of Exchange mailboxes. Some scripts that might provide a start are available, such as the one written for Office 365 and posted in the TechNet Gallery.

However, if you’re getting serious about working with EWS my advice is to head over to the blog written by Exchange MVP Glen Scales to pick up some of the great code examples that he has posted (and explained) there. For example, this post explains how to use EWS and PowerShell to process delegate information.

Still, we have a way to identify mailboxes that participate in delegate scenarios and are therefore candidates to be put on hold. As you can imagine from this explanation, there’s quite an amount of administrative effort required to make sure that holds are applied in a systematic and ongoing way.

So what about the second workaround suggested by Microsoft, to disable OWA access for users who are on hold. First, we have to identify those mailboxes. This is readily done with a one-line EMS command:

Get-Mailbox –ResultSize Unlimited | Where-Object {$_.LitigationHoldEnabled –eq $True –or $_.InPlaceHolds –ne $Null} | Format-Table Name, LitigationHoldEnabled, InPlaceHolds

We can disable OWA access for these mailbox with an amended command:

Get-Mailbox –ResultSize Unlimited | Where-Object {$_.LitigationHoldEnabled –eq $True –or $_.InPlaceHolds –ne $Null} | Set-CASMailbox –OWAEnabled $False


Any attempt by the user to access OWA thereafter will result in them being informed that their account is disabled. In reality their account is fine and it’s just OWA access that has been turned off. They will still be able to use Outlook, ActiveSync, and OWA for Devices (and POP3 or IMAP4 if they really want).

The conclusion of this exercise is that the easiest workaround is to disable OWA access for mailboxes that are under litigation or in-place hold. It was fun to work out how to discover which mailboxes use delegate access, but the ongoing maintenance and checking that is required to keep tabs on delegate access is probably too onerous to undertake in a production environment. After all, you always have other things to do to keep Exchange on-premises or Exchange Online working well.

Follow Tony @12Knocksinna

Posted in Cloud, Email, Exchange, Exchange 2013, Office 365, Outlook, Uncategorized | Tagged , , , , , , , , , , , , , | 3 Comments

Some technology updates, some glitches, mostly good

Since returning from the network wilderness that sometimes afflicted us during our recent trip to France, it seemed like a good idea to complete some technology refreshes that had been on the back-burner during vacation.

The first was to remove the Windows 8.1 Developer Preview from my Nokia Lumia 1020 in an effort to convince the phone that it should really install Nokia’s “Cyan” upgrade for Lumia phones. I don’t regret following Paul Thurrott’s advice to install the Developer Preview because it has worked well on the 1020 for the last few months. However, it was disappointing that the 1020 wasn’t able to use the Cyan upgrade once it was released as this contains some nice enhancements to the camera among other things.

I used the process described on First, I took a backup of the phone first (always a good place to start) and then reversed course to install the original software. This was done by downloading the Nokia Recovery Software Tool and running it to apply the necessary magic. The tool required an update, which slowed things down, and after a few false starts (mostly my fault) and many warnings that failure to do this, that, or the other thing would lead to horrible consequences for the phone, the 1020 was back to where it started and was then able to download and apply the Cyan update.

Restoring the phone from the backup brought the apps that were previously installed back onto the phone but I was surprised to discover that settings were not recovered. For instance, podcasts that I had subscribed to were not there, FM radio favourites were missing, and so on. In any case, it didn’t take long to put everything back into the right shape and I am now happily experimenting with the Cyan updates.

Next on the list was to swap out the 32-bit version of Google’s Chrome browser for the newly-released 64-bit edition. I had been running the “Canary” (development) version of the 64-bit code since June and it seemed pretty stable, so I was happy enough to remove the 32-bit version for the promise of greater stability and security promised by its 64-bit counterpart. The process involved removing both the 32-bit and 64-bit (test) browsers and then reinstalling the supported release of the 64-bit code.

So far the only glitch I have encountered is when joining Lync Online meetings. Clicking on a meeting link launches Chrome to connect to the meeting and an invitation to install the Lync Web App plug-in. This works well with the 32-bit version of Chrome but not so far with the 64-bit version. The workaround is easy – I switch to IE11 and paste the link into it to make Lync happy.

The last item to report is the acquisition of a Surface Pro 3 i5 with a Type keyboard. I chose the 128GB model on the basis that most of the information I would use with the device would be stored in OneDrive.

I bought one of the original Surface Pro models (we also have an original Surface RT in the house) and had used it for many trips since. Its last voyage was when my son took it with him on a month-long visit to the U.S. The Surface functioned perfectly throughout and proved to be a good choice for a space-constrained traveller before it hit some bad luck on the penultimate leg (LAX-ORD) when, for an unknown reason but likely a bag in an overhead compartment, the Surface ended up with a cracked screen. Microsoft offers a repair service but the prospect of spending €231 for a new screen for a device that is showing its age didn’t seem an attractive option.

So far everything is going well but I haven’t really stressed the Surface yet. I like the form factor and the pin-sharp screen and the new Type cover seems to be more responsive and easier to use than the last version. I also hear good things about the docking station as this addresses the lack of USB ports and other connectors. However, the combination of Surface Pro, cover, and docking station (an extra €205 in Ireland) quickly adds up and marks this out to be a premium laptop or tablet or whatever it’s supposed to be.

I leave for a two-week trip to Orlando and Las Vegas (Exchange Connections) on Saturday and will bring the Surface Pro 3 instead of my normal HP Envy 17-inch i7 mega-laptop (a great workhorse but oh so heavy…) and this will give me a better idea of its capabilities.

Speaking of technology, is anyone else frustrated and under-impressed at the way that Facebook updates your news feed? It appears to include articles and updates on a purely arbitrary and ever-changing basis that never gives a feeling of predictability. It must be the way of the new world…

Follow Tony @12Knocksinna

Posted in Technology | Tagged , , , | Leave a comment

Exchange Unwashed Digest – August 2014

I spent a lot of August in France but that didn’t stop the constant demand for new content to appear in my “Exchange Unwashed” blog on Here’s what was published during the month.

Exchange 2013 CU6 hybrid and co-existence bugs cause administrators to despair (August 30): Exchange 2013 CU6 was supposed to be all about enhanced public folder scalability but as it turns out, the update had a few twists of its own to offer. Hybrid connectivity with Office 365 suffered because of a bad configuration file while co-existence with Exchange 2007 servers proved problematic because the two versions didn’t understand each other. Oh dear… You would really wonder how Microsoft tests this stuff before they release code to customers.

OWA bug compromises item preservation for litigation and in-place holds (August 28): No bug is good but this is a bad one because it means that a corrupt user can exploit a weakness in Outlook Web App to remove incriminating information from an Exchange 2013 server. Microsoft’s competitors in the compliance space must have been overjoyed when they realized what had happened – but I wasn’t amused.

Exchange 2013 Cumulative Update 6 begins to address public folder scalability (August 26): I was so optimistic when I wrote this post because CU6 appeared to be all good news. Modern public folders had crippled scalability and it took far too long for Microsoft to recognize the problem and move to fix it. But at least improvements were happening and it seemed like CU6 was the first step along the path to acceptable scalability. Then other stuff happened. Enough said.

TechEd Europe session selection not good news for on-premises customers or independent voices (August 22): I was pretty annoyed when I read the list of Exchange-related sessions that were selected by Microsoft for TechEd Europe in Barcelona at the end of October. Too few sessions and none to be delivered by independent speakers, despite many good session proposals submitted by European MVPs. At least the Exchange product group did something and changed the schedule to allow 1.5 MVPs to speak. Still disappointing though if you think about what might happen at the new Microsoft uber-conference in Chicago next May.

Another opportunity for automation in eDiscovery for SharePoint 2013 and Exchange 2013 (August 21): It’s great to have a common eDiscovery platform shared by SharePoint and Exchange but it would be nice if it were easier to use. Software can automate common operations and smooth the way that users interact with functionality. It would be nice to see more more automation here.

The joy of an impractical 100,000 Exchange 2013 mailbox configuration (August 19): I have no problem whatsoever when storage companies produce configurations to guide customers into what is possible using their solutions. I get heartburn when those configurations belong in cloudcookoo land, which is where I think the worthy people of Nimble Storage were heading when they came up with their suggested configuration to support 100,000 Exchange 2013 mailboxes. But see what you think. Perhaps you’ll like it.

Rapid development in Office 365 reflects current software engineering practice (August 14): A somewhat reflective piece on how software engineering disciplines and techniques have evolved to a point where getting new features out is really all that’s important, which is why I think we hit so many quality problems in software.

Update causes Outlook 2013 to fail to open archive mailboxes (August 13): Another patch, another problem. This time it was with Outlook 2013 when a patch provided through the normal “Patch Tuesday” mechanism caused merry hell with archive mailboxes. Well, you couldn’t get to the archive mailboxes… on either on-premises or cloud servers. So at least the problem was felt by all sides. And who needs that stuff in archives anyway?

2TB seems like such a good size for a mailbox database (August 12): How big should a mailbox database be? Well, that all depends on your appetite for risk and how much you like to restore very large backups. Or just deploy multiple copies in a DAG and grow your databases up to around 2TB, which seems just about right.

Why an Office 365 update caused the Exchange 2013 HCW to crash (August 7): Bored of hybrid connectivity woes yet? Well, August 2014 seemed to be the month when things went south for the hybrid folks. A change made in Office 365 suddenly caused every supported version of the connectivity wizard to fail. Can we say “ill-advised” change? I think we can…

Exchange 2007 approaching the end of the line – slowly (August 5): The nature of enterprise IT is that things move slowly when it comes to the planning process for software upgrades. Exchange 2003 expired this year and Exchange 2007 will expire in 2017. That’s still some time away, but you had better get planning soon.

So there we are. Not a particularly nice month in terms of tales of woe and problems. September 2014 should be better. At least there’s Exchange Connections to attend in Las Vegas. I’ll report from there during the month. Stay tuned!

Follow Tony @12Knocksinna

Posted in Cloud, Email, Exchange, Exchange 2013, Office 365, Outlook 2013, SharePoint 2010, Technology | Tagged , , , , , , , , , , , , , | 1 Comment

Visiting Omaha Beach and some Wi-Fi woes

Omaha Beach

Omaha Beach

Those of you who know me will realize that I am a bit of a history buff, so it should come as no surprise that the last night on a recent trip to France found us in Vierville-sur-Mer en route to the Cherbourg ferry. Vierville-sur-Mer is a very small village, but it’s famous (in some places) because of its location on Omaha Beach, possibly the most famous of the five assault D-Day beaches in 1944. Given the recent 70th anniversary of the D-Day landings, it seemed like an appropriate place to stop.

Large parts of Normandy are rural and the area around Omaha Beach is lacking in good hotels. The British beaches (Juno, Sword, and Anvil) are better served because of the larger villages and towns within easy reach, including Bayeux and Caen. By comparison, the U.S. Army landed in the countryside, and so it remains today.

We were happy to end up in the Hotel du Casino, which occupies a spectacular position overlooking the western end of Omaha Beach. Looking to the west, you can see Pointe du Hoc, while the complete beach unfolds itself to the east toward the American cemetery at Colleville-sur-Mer.

Hotel du Casino

Hotel du Casino

The U.S. National Guard memorial is just outside the door of the hotel and is built on top of a “Type 677” casemate containing an 88mm cannon that did horrible damage on D-Day. One of the five “draws” (D-1) that led through the cliffs fronting the beach goes by the door of the hotel up to the village proper. Here are many stone houses that were fought over during D-Day and a 12th century Norman stone church whose bell tower was destroyed that afternoon and rebuilt after the war.


Vierville-sur-Mer church tower

Vierville-sur-Mer church tower

Vierville is the location of the “Dog” and “Charlie” landings and was the most heavily defended part of Omaha Beach. The devastation depicted in the opening of the film “Saving Private Ryan” was based on the experience of the 29th Infantry Division and the huge casualties that they incurred in the opening hours of June 6. The film didn’t use Omaha Beach as a location and used Curracloe Beach in County Wexford, Ireland instead. Having walked Curracloe too, I can report that the two beaches are indeed very similar.

The book “Omaha Beach: D-Day, June 6, 1944” by Joseph Balkoski is a great resource for explaining the sequence of events as they happened on D-Day. An equally good companion volume covers the landings at Utah Beach. Looking at the surviving fortifications today, it’s easy to realize how the enfilade fire from machine guns and artillery was able to wreak havoc on the landing troops as they made their way across soft sand to the relative safety of the shale and sea wall at the high tide mark.

Another thing that you soon notice is the speed of the advancing tide. A decision had been taken by the Allies to land at low tide so that the landing craft and other small boats that took troops in would be able to see the mined obstacles set by the Germans. But the tide here rises terrifically quickly and soon advances to the sea wall, meaning that wounded soldiers had to be rescued and moved or left to drown. It’s a sobering thought.

The hotel was fine except that its Wi-Fi system stubbornly refused to work, which meant in turn that I got no work done. What was worse was the authentication system that the hotel used to issue usernames and passcodes to connect to the non-functioning Wi-Fi system. I couldn’t help wondering exactly how many people passing by would attempt to steal their bandwidth and whether it wouldn’t just be easier if an open Wi-Fi system was offered. In any case, it stayed down and I stayed off the air.

We returned to Ireland on the MV Oscar Wilde on the Irish Ferries route between Cherbourg and Rosslare. Weirdly, the Wi-Fi system on the ferry also refused to co-operate and further impacted my ability to work. I ended up trying to help the chief engineer and chief purser to figure out what the problem might be. The system used on the ferry is designed for maritime vessels and controlled via satellite from Norway, so local tweaking of servers and the like was out of the question. The most I could do was identify its total failure to allocate IP addresses or a DNS server to connecting clients. Interestingly, one of the crew was able to connect and I was able to clone their IP settings and connect my PC. The network worked but it just wasn’t servicing clients. Isn’t that always the way?

Follow Tony @12Knocksinna

Posted in Travel | Tagged , , | Leave a comment

Dealing with Inbox Clutter – with or without vacations

The news that Daimler has decided to implement software that deletes email received by users when they are on vacation might make other companies believe that such a course is a very good thing. After all, you’re not supposed to be thinking about work when you are on vacation. Right?

I’m not so sure. But then again, I am someone who attempts to operate a “zero latency inbox.” In other words, email is processed as soon as possible after it arrives by being assigned to a folder for later processing, ignored, or deleted. The idea is to prevent an accumulation of messages in the Inbox. I admit that this technique was much easier to use in the days when not quite so much email circulated, but it’s something that I have done for thirty-odd years now.

Arriving back from vacation to find hundreds or thousands of messages demanding attention in an Inbox can be depressing. In fact, it can be hard to know where to start to work through the backlog. What messages are most important? What contain information about problems that are long since solved? Or information that has been superseded by developments since? Or notice of meetings and other events that have happened in the interim? Not to mention the detritus found in all mailboxes formed of auto-replies, out of office messages, service items, and so on.

Microsoft is attempting to solve the problem in two ways. First, they have the People View feature that is now implemented in Outlook Web App (OWA) for Exchange Online (Office 365), but not yet for on-premises Exchange. The idea is that Exchange identifies the correspondents that are most important to a user and then filters messages that arrive from those people so that they show up in a set of special views displayed by OWA. Behind the scenes, an agent analyses inbound traffic to the Inbox and figures out the most important correspondents on a regular basis. Thus, when you arrive back from vacation, OWA can show you neatly sorted lists of messages that should be important to you.

I’ve been using People View for three months or so and find it an interesting and worthwhile feature that will assist people who receive a lot of email. However, I consider the “Clutter” feature much more interesting because it will discard a lot of the rubbish (the clutter) that obscures really important messages. Clutter does this by using a mailbox assistant to learn about your email habits. For example, if you always respond to messages from “Jane” and tend to ignore those that come from “New company announcements”, then Clutter knows that Jane is important to you and that her messages should be prominently displayed whereas it’s safe to shuttle company announcements off into a holding folder. Those messages can still be accessed but they are removed from view until required.

Of course, when People View and Clutter are operating in tandem, they will be able to provide a filtered list of important messages from important correspondents and hopefully reduce the hundreds of messages that arrive during a vacation (or even overnight) into more digestible chunks of prioritized communications.

Clutter won’t be with us until the end of 2014 and the signs are that this will be a cloud feature that might not make it to an on-premises version anytime soon, for such are the complexities involved in the machine learning algorithms that attempt to make sense of user behaviour.

Neither feature will reduce the stress that some people feel when their mobile devices birr, whirr, or buzz to announce the arrival of new messages. Turning off the device is one solution but that can be hard when a single mobile device is used as the fulcrum of private and business communications. The temptation always exists to have a quick look at what’s happening back at the office, the latest state of inter-departmental politics, who is stabbing whom in the back (in the nicest possible way), or what deep and dark plot is being hatched against competitors. Some business email is actually fun and informative, but most can be depressing when you’re supposed to be on vacation.

I’m not sure that Daimler is right to suppress all email for holidaying employees. I’m sure that they made the decision in the best possible way after some in-depth studies, employee questionnaires, and so on. But I wonder what will happen the first time some executive misses an important opportunity because software quashed their email…

Follow Tony @12Knocksinna

Posted in Cloud, Email, Exchange, Office 365, Outlook | Tagged , , , , , , , , | Leave a comment