Exchange 2013 Inside Out – Errata

One of the horrible things about being an author is that errors creep into text and get printed. It’s a dreadful feeling to read printed text and then suddenly realize that a problem is there. It could have occurred during the original writing, via a change during the technical editing process, during copy editing, or when the text is laid out by desktop publishing to create the final PDFs used by the publisher. Even though we do our best to read and re-read text to find and fix problems, some stuff always seems to sneak through. For whatever reason, it’s the equivalent of a software bug.

Books don’t have patches. Content has to be electronically recreated for digital publishing or printed copies. It’s not just a matter of fixing words as the fix might cause a page to overflow or an index entry to be altered. In short, fixing text is more complicated than it seems.

I’m working with Microsoft Press to fix the problems that I know of so that the updated text feeds into their publishing process. In doing so, I plan to record the problems here so that it’s available to anyone who has a copy. Feel free to cut and paste (literally – on paper), should that please you.

Sorry for the bugs.

– Tony

Chapter 1 – Introduction

Nothing to date

Chapter 2 – Installation

There are six references to Setup.com in the chapter. For whatever reason, probably incompetence on my part, this should be Setup.exe in each instance.

Chapter 3 – Exchange Management Shell (EMS)

Page 104: Some people suggest that this is better code to use to connect to Exchange with PowerShell ISE:

$PSISE.CurrentPowerShellTab.AddOnsMenu.SubMenus.Add(
 “Connect to Exchange”, {
 $user = Get-Credential
 $Server = Read-Host “Connect to what Exchange server “
 $connectpoint = “http://$Server.contoso.com/PowerShell/”
 $ExSession= New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $connectpoint -Credential $user
 Import-PSSession $ExSession
 },
 “Control+Alt+1”
)

Page 109: Seems like 10,000 became 1,000 in this extract:

Too many objects

By default, EMS returns up to 10,000 objects in response to cmdlets. (The value in Exchange 2007 is 5,000.) Therefore, if you run a cmdlet such as Get-Mailbox, Exchange will return up to 10,000 mailboxes if they are available. If you work in a small Exchange organization that supports fewer than 10,000 mailboxes, you don’t need to worry too much about the number of objects you have to deal with because PowerShell will likely return relatively few objects, and things usually progress quickly. However, it’s a different situation in large organizations, where you have to pay attention to the filters you specify to retrieve data or override the default limit for returned objects by specifying the ResultSize parameter for cmdlets. For example, to let EMS return as many mailboxes as it can find, you could use a command like this:

Get-Mailbox –ResultSize Unlimited

This command will work, but it will be very slow because EMS has to read every single mailbox in the organization. Think about how long this might take to execute in an organization that supports more than 300,000 mailboxes. In these situations it’s always better to specify a filter to restrict the number of objects EMS looks for and returns.

Chapter 4 – Role Based Access Control (RBAC)

Nothing to date

Chapter 5 – EAC and mailboxes

Page 215: The text:

Mailboxes that use the quotas inherited from the database settings have their UseDatabaseQuotaDefaults property set to False, whereas those that have individual quota settings have the property set to True.

I got this the wrong way round. The first reference should say True, the second should say False.

Should state opposite $true then $false

Chapter 6 – Groups and other objects

Page 282. I notice that the syntax for the command starting $Filter is mangled. It should be:

$Filter = (Get-DynamicDistributionGroup -Identity “Vice Presidents (QBDG)”).RecipientFilter

Chapter 7 – Address Lists

Nothing to date

Chapter 8 – The Store

I wanted to add this “Inside Out” sidebar, but it seems to have been cut.

INSIDE OUT   Tuning .NET for optimum Store performance

The Store makes heavy use of the .NET Framework. In their tuning exercises, Microsoft discovered that disabling an aspect of a .NET component called the garbage collector benefits Store performance on both standalone and multi-role servers. To make the change, you need to download and install either KB2803754 (Windows Server 2008 R2 SP1) or KB2803755 (Windows Server 2012) and create a new registry DWORD entry called HKLM\Software\Microsoft\.NETFramework\DisableRetStructPinning. Set the value to 1 and the Store will use less memory for each of its worker processes.

Chapter 9 – High Availability

Page 485: Another change that didn’t make the final text. First paragraph under the bulleted list should read:

Transaction logs are not copied to servers that host database copies when block mode replication is in use because the passive servers are already building and replaying their own copy of logs. However, as soon as the Replication service determines that block mode is not appropriate (for instance, the replay queue has begun to grow), it reverts to file mode replication and starts to copy transaction logs again.  The advantage of block mode is that transactions are dispatched immediately when they are available to the log buffer of the active database. Transaction data arrive to the servers that hold passive databases as quickly as the server hosting the active database can dispatch data across the network.

Chapter 10 – Moving mailboxes

October 7, 2013: Not an error as such, but I wish that I had added this text to the chapter.

Versions

You have to initiate moves between Exchange 2013 and lower versions (in this case, Exchange 2010 and Exchange 2007) from Exchange 2013. This might seem strange as MRS also runs on Exchange 2010 servers. However, the reason is simple – Exchange 2013 knows about the requirements and format used by earlier versions but Exchange 2010 has no knowledge of Exchange 2013. Microsoft updates mailbox content and settings in each version of the product and it’s obviously critical that data is preserved as accurately as possible when it is moved between versions. For this reason, you initiate mailbox moves from legacy versions of Exchange (either individually or through a migration batch) on an Exchange 2013 server, using either EAC or EMS. This situation should not come as a huge surprise to administrators because traditionally Exchange has always required that mailbox moves should be initiated from the higher version, so Exchange 2013 simply follows the rule that the latest version always wins.

Chapter 11 – Compliance

Page 658: You cannot define a retention tag to the Contacts folder, despite the fact that I say so here.

On page 659, there’s no point including the Sync Issues folder in the set of folders that you worry about in a retention policy because synchronization logs stay on the PC and never appear on the server, so MFA can’t process them! Consequently, we also need to remove the reference to Sync Issues from Table 11-3 on page 664 and the reference to the tag called “Sync Issues 1” from the code on page 674 as well as the reference to the Sync Issues folder on page 675. Call this issue some brain-dead thinking on my part…

Page 661: Inside Out Sidebar should read:

INSIDE OUT Some items are timeless

Items in some folders tend to be more timeless than general-purpose messages, so you should think carefully through the potential consequences when you create retention policy tags for folders. For example, people usually want to keep important project documents for a long time, so it might be best to create tags that enable users to mark these items not to expire. To do this, they should create a personal tag with a Never retention period, which indicates to Exchange that the item should be held indefinitely and neither deleted nor archived by MFA.

Chapter 12 – Public folders and site mailboxes

Page 770: Inside Out sidebar (don’t know what happened here). Real text follows:

INSIDE OUT Knowing which public folder mailbox holds the writeable hierarchy

As you can see from Figure 12-2, many public folder mailboxes can be active in an organization, but only one holds the writeable copy of the public folder hierarchy. EAC shows you which public folder mailbox contains the primary hierarchy, but you can also find out and discover how EAC knows which mailbox holds the writeable copy of the public folder hierarchy by issuing this command:

Get-OrganizationConfig | Select RootPublicFolderMailbox

However, this command only returns the globally unique identifier (GUID) of the public folder mailbox, which is not really useful to a human. The better approach is to run this command:

Get-Mailbox -PublicFolder | Where {$_.IsRootPublicFolderMailbox –eq $True} | Select Name, ExchangeGuid

This returns a list of all public folder mailboxes and then applies a filter to extract the mailbox that contains the writable hierarchy.