BUG: Lync Stress Tool and SQL Named Instances

The Lync Server Stress and Performance Tool has a major flaw when using a named SQL instance for the Lync back-end databases.  This post is based on the 7577.120 version of the tool and will not go into all of the ins and outs of the tool.

Problem:

First off, the GUI and field descriptions in the User Creation tool are very misleading.   Looking at the “Server” tab, it seems pretty straight forward on what to enter in the SQL fields…

Not the case, according to the Documentation, the following descriptions are used for those fields:

• SQL BE Machine – type the name of the SQL Server Back End physical node
• SQL Instance – type the database name

The database name in the Instance field?  Ok, so where do I put my Instance name?  All good questions… the problem is that this is the bug.  The tool does not allow for the SQL instance to be properly entered.  The following examples show different permutations trying to get the right information entered to represent the actual topology.

Symptoms:

Note: my actual SQL config is LABSQL01\Lync (Servername\Instance)

Variation #1:

The tool will refer to the database and instance name as “Lync” (obviously, my database is not named “Lync”):

Variation #2:

The tool will refer to the database and instance name as “RTC”(obviously, my SQL instance is not named “RTC”):

Variation #3:

The tool will add “RTC” as part of the Instance name and also the DB name:

Variation #4:

The tool will add “Lync\RTC” as part of the Instance name and also the DB name:

Conclusion:

Basically whatever is entered into the “SQL Instance” field will be used as the Instance and database name.

This could potentially be a great tool to use in the field, but currently it is only useful in a handful of deployments (Standard Edition or default instance installations of SQL back-end).  This has been reported to Microsoft and has been acknowledged as a known issue.  Hopefully a new release will soon be out.

BUG: Exchange 2010 Personal Archive Display Name in Outlook 2010

This post is based on Exchange 2010 SP1 with Update Rollup 1 and Outlook 2010 with latest updates.

Let’s consider that we would like the name of the Personal Archive to be more descriptive for our users.  We can change the Display Name for the archive to display whatever we want.  There appears to be a bug with the display name of the Personal Archive Display Name in Outlook 2010.  OWA displays the name correctly. 

Let’s look at default settings of my Personal Archive by running the following command:

Get-Mailbox 2010sp1b | fl *archive*

The default view from Outlook 2010 doesn’t match the exact Display Name of “Online Archive – 2010SP1b” as shown above from the “ArchiveName” parameter:

The default view from OWA does match the “ArchiveName” parameter:

Now let’s change the “ArchiveName” parameter to something more descriptive by running the following command:

Set-Mailbox 2010sp1b –ArchiveName “KEEP FOREVER”

Again, the view in Outlook 2010 does not update to match the “ArchiveName” parameter:

But, OWA 2010 does update to match:

Anyone know of or have a fix to force Outlook 2010 to update the Archive Display Name?

BUG: Exchange 2010 Read Receipt Processing

It was recently brought to my attention by a client that was just migrated to Exchange 2010 that their read receipts were not processing correctly.  I decided to reproduce this issue, and sure enough I had the same problem.  The reason I say this is a bug with Exchange 2010 is that I have tested this scenario on Exchange 2003, Exchange 2010 (with RU4), and Exchange 2010 SP1 Beta.  I have also tested with Outlook 2007 and 2010 clients. 

This issue is common to email that flows through an Exchange 2010 HUB server, regardless of what Outlook client is used.  If the mailboxes are homed on Exchange 2010 SP1 Beta and the email flows through an Exchange 2010 (with RU4) HUB server, this issue persist.  If the mailboxes are homed on Exchange 2010 (with RU4) and the email only flows through an Exchange 2010 SP1 Beta HUB server, the receipts are processed normally.  Now let’s look at the issue in detail.

When sending an email, a user has the option to request a delivery receipt and a read receipt.

After the delivery and read receipt appear in my Inbox, I should be able to go look at the original message in the Sent Items and view the tracking information.

Expected behavior and what we see with Exchange 2003 mailboxes: Behavior with Exchange 2010 mailboxes:

So how does this tracking information get tracked and processed by Exchange?  When a user tags the original message to request a delivery and read receipt, a property tag gets attached to the message: PR_REPORT_TAG.  This property tag is used to match the original message and the receipts and update the tracking information in Outlook and should exist in all related messages (original, delivery receipts, and read receipts).  We can use a tool like MFCMAPI, to view the properties of the different messages.

Original message:

Delivery receipt:

Read receipt:

Just so that you believe me that property tag should exist in the Read receipt, here is the property view from the Exchange 2003 read receipt:

Read receipts are generated by Exchange and for some reason the Exchange 2010 HUB is removing the PR_REPORT_TAG property from the read receipt during transport.  Again, if the PR_REPORT_TAG is not in the message, it will not update the tracking information in the original message.  The tag must be present and the value match between all of the related messages.

Note: Again, I have tested this scenario on Exchange 2010 SP1 Beta and it works as expected.  Not sure if Microsoft will release a patch for Exchange 2010.

I will talk about a “workaround” in by next blog post about end-user Message Tracking and Delivery Reports.