Exchange 2010 Public Folders: Part 2

Posted on February 12, 2011 by Tony Redmond

This content comes from a chapter removed from my book Microsoft Exchange Server 2010 Inside Out, also available at Amazon.co.uk (including a Kindle edition). The first part of the chapter is available in this post. Now let’s get on with some more discussion about public folders.

Creating new replicas

The default state for a public folder is that a single replica exists in the database where an administrator originally creates the folder unless replicas exist for the parent folder, in which case Exchange creates replicas for the new child folder in the databases where replicas exist for the parent.

Having a single replica of a folder may be the most appropriate state for the folder if all users are able to make reliable connections to the server that hosts the database. However, in large or distributed environments it is common to create several replicas so that users can always make a local connection. We will discuss how to control the process by which Exchange decides to which replica a client should connect in the “Removing public folders” section. For now, let’s review how to create the replica folders.

Configuring replicas for a public folder

Open the public folder management console and locate the folder that you want to replicate. Click Properties and then select the “Replication” tab (Figure 1). You will see the list of databases that currently have replicas and will be able to add new databases. The equivalent EMS command is:

Set-PublicFolder -Identity '\Departments\Finance' -Replicas 'PFDatabase1','PFDatabase2'

Replication is performed through special messages sent between the servers (using SMTP) that host the public folder databases that include the replicas. Each database has a replication schedule that typically replicates new items or other content updates for public folders every 15 minutes. Content is broken up into relatively small (by today’s standards) 300KB messages to ensure fast and efficient distribution. You can force immediate replication by selecting the Update Content option from the action pane. This might be required if a user wanted the immediate distribution of some important information throughout the organization. If you don’t already have the public folder management console fired up and ready to go, it’s probably quicker to invoke the Update-PublicFolder cmdlet from EMS. In this instance, we force replication of the contents of the Press Releases folder using the folder from the database on server ExServer1:

Update-PublicFolder –Identity '\Departments\Marketing\Press Releases' –Server ExServer1

By comparison to folder content, changes to the folder hierarchy are replicated as soon as they occur, so the addition or deletion of a folder should replicate throughout the organization very quickly.

Mail-enabling a public folder

A mail-enabled public folder is able to accept new items via email. If anonymous access is permitted, anyone will be able to create a message, address it to the folder, and send it to Exchange for delivery. A public folder is mail-enabled with the Enable-MailPublicFolder cmdlet. Alternatively, you can select the folder from the Public Folder console and click on the “Mail Enable” option in the action pane. Mail-enabled public folders are listed in the console with a different icon from folders that are not mail-enabled. In this extract from EMC (Figure 2), four mail-enabled public folders are listed.

Viewing mail-enabled public folders

When you mail-enable a public folder, Exchange also reveals it to users in the GAL, albeit with minimal useful detail (Figure 3). It might not be desirable to have public folders shown in the GAL; you might prefer to have users post to the folder by addressing messages to the folder’s SMTP address. These commands mail-enable a public folder and hide it from the GAL:

Enable-MailPublicFolder –Identity '\Departments\Finance\Forms'
Set-PublicFolder –Identity '\Departments\Finance\Forms'
–HiddenFromAddressListEnabled $True

How a mail-enabled public folder appears in the GAL (as seen with OWA)

You can also hide a public folder from Exchange address lists by selecting it in the Public Folder management console, view its properties, navigate to the Exchange General property page, and select the checkbox to hide the folder. Hiding mail-enabled public folders only conceals them from users. Even if you hide a mail-enabled public folder from the Exchange address lists, administrators will continue to see these objects listed in the picker dialogs used to select recipients for various tasks such as adding recipients to distribution groups.

Behind the scenes, when you mail-enable a public folder, Exchange creates a new object for the folder in the Microsoft Exchange System Objects OU. Figure 4 shows the attributes of a mail-enabled public folder as viewed through the ADSIEdit utility. The new object is used to hold properties of the public folder such as the proxy email addresses, mail tips, and so on. The properties of the new object can then be viewed with the Get-MailPublicFolder cmdlet and manipulated with the Set-MailPublicFolder cmdlet.

Viewing the attributes of a mail-enabled public folder with ADSIEdit

The mail-related properties that are available to mailboxes, groups, and contacts are also available for public folders. For example, here’s how to set up moderation for a public folder so that only users from a specific group plus the moderator can post items. Any other attempt has to go through moderation.

Set-MailPublicFolder –Identity '\Departments\Finance' –ModeratedBy 'Redmond, Tony' –MailTip 'Only members of the Finance Department can post to this folder'
–ByPassModerationFromSendersOrMembers 'FinanceUsers' , 'Redmond, Tony'
–ModerationEnabled $True

You can disable a mail-enabled public folder with the Disable-MailPublicFolder cmdlet. This will also remove the Active Directory object and the GAL.

Disable-MailPublicFolder –Identity '\Departments\Finance\Forms'-Confirm:$False

Bad email addresses for email-enabled public folders

No system folder needs to be mail-enabled. However, you may see errors flagged when you apply an email policy to these objects. The likely cause is that these folders were enabled for email in a previous version of Exchange and their names or aliases include spaces or special characters that cannot be used in SMTP addresses, and so are found to be invalid when Exchange attempts to use them to create email addresses according to the email policy. If you see an error like this, you can disable email for the folders and remove their email addresses with this code:

Get-PublicFolder '\non_ipm_subtree' –Recurse –ResultSize Unlimited | Disable-MailPublicFolder –ErroractionSilentlyContinue

Afterwards, you can fix the names of the folders to remove any offending characters from their names or aliases and then re-enable them for mail.

Removing public folders

The Remove-PublicFolder cmdlet deletes a public folder from the public folder hierarchy and removes all content and replicas that exist in public folder databases in the organization. The simplest deletion is to remove just one folder. For example:

Remove-PublicFolder –Identity '\Departments\Finance\Tools' –Confirm:$False

This command works if the folder has no children. If a child folder exists you’ll be told that you can’t delete a parent folder until you first remove any child folders. You can do this with much the same command by adding the –Recurse parameter to force Exchange to locate and remove any child folders before it removes the parent.

Remove-PublicFolder –Identity '\Departments\Finance\Tools' –Recurse –Confirm:$False

In these examples I’ve suppressed the confirmation prompt because I am pretty confident about the folder that I want to delete. A delete of a public folder cannot be reversed as there’s no equivalent of a deleted items folder for public folders or the items that they contain – unless you use the ExFolders utility to recover the deleted folder. Even then, ExFolders might not be able to recover a deleted public folder, so it’s a good idea to be sure that you really want to remove a folder before you proceed to do it.

It’s a good idea to clean up old and obsolete public folders on a regular basis. You can scan for folders that don’t hold a lot of content or haven’t been accessed recently. This command fetches the set of folders in the hierarchy as known in the public folder database on a server and generates statistics for each folder before sorting the set by the last modification time before outputting details into a report.

Get-PublicFolder –Identity '\' -Server ExServer1 -Recurse
-ResultSize Unlimited | Get-PublicFolderStatistics | Select Name, ItemCount, TotalItemSize, LastModificationTime| Sort-Object LastModificationTime
–Descending | Format-Table –AutoSize> C:\Temp\PFReport.txt

Controlling public folder referrals

Any public folder can be replicated to databases on multiple servers. The public folder hierarchy is always replicated to every public folder database so that each server can present a complete view of every public folder that is available in the organization to clients that request this data. The folder hierarchy lists every folder, its permissions, and details of the servers that currently host databases that contain replicas of each folder. Replicas of every folder do not necessarily exist in every public folder database. When public folders exist in an organization, every mailbox database is associated with a public folder database and clients always attempt to connect to folder replicas in the public folder database associated with their mailbox database. If clients need access to a folder replica that is not present in the database that they are currently connected to, Exchange creates a referral to the most appropriate public folder database that contains a replica. You can view the public folder database that is used by a mailbox database by looking at its properties through the Client Settings tab. As you can see in Figure 5, the IT Department database currently uses PFDatabase1, so any connections from mailboxes hosted by this database will go to PFDatabase1. If this isn’t the most appropriate public folder database to use, we can select another one – perhaps a public folder database that is hosted by the same server as the mailbox database.

Selecting a public folder database for a mailbox database

When a mailbox database is created, Exchange checks the available public folder databases to decide which to associate with the new mailbox database. If a public folder database is available on the same server, it is selected. If not, the first public folder (listed alphabetically) in the organization is used. Over time, this leads to a certain imbalance in the workload going to the first public folder database. To check the current allocation of mailbox databases to the available public folder databases:

Get-MailboxDatabase | Select Name, PublicFolderDatabase

You can then move work by updating a mailbox database as follows:

Set-MailboxDatabase -Identity 'IT Department'-PublicFolderDatabase 'PFDatabase2'

The default mechanism used to determine the best referral is based on Active Directory site link costs. First, Exchange looks for servers in the local site to see if there are public folder databases available that contain the required folder. If no local servers are available, Exchange builds a list of available servers that host public folder databases in other sites and orders them by cost. Exchange then attempts to contact each server to see whether they have an available replica and will connect to the first replica folder that it finds.

It is possible to ignore the Active Directory site link costs and use a custom referral list instead. To do this, go to the Organization Configuration node of EMC and then Mailbox, and then select the public folder database with which you want to work. Now click Properties To and then select the Public Folder Referral tab. As expected, the default option is to use Active Directory site costs. However, as shown in Figure 6, you can create a custom list of mailbox servers (that host public folder databases) and assign each a cost from 1 to 100 to have Exchange use this list when it determines client referrals. Costs are prioritized from lower to higher, so you should assign a cost of 1 (one) to the server that you want to direct client referrals to whenever possible and any other value up to 100 for the other servers. The higher the cost value, the less likely Exchange will use it for client referrals.

Setting the referral cost for a public folder database

You can create a custom referral list with EMS too. In the example shown below, we select create a list of three mailbox servers that host public folder databases and assign each server with a different cost to provide Exchange with an order to use to check the servers for public folder replicas. Finally, we tell Exchange to use the custom server list rather than using the default Active Directory site cost.

Set-PublicFolderDatabase -Identity 'ExServer1\PubFolders1'
-CustomReferralServerList 'ExServer2:1','ExServer3:10','ExServer5:25'
-UseCustomReferralServerList $True

Posted in Exchange, Exchange 2010 | Tagged , , , | 60 Comments

Exchange 2010 SP1: Protecting data with a BSOD

Posted on February 10, 2011 by Tony Redmond

In conversation with an administrator of one of the world’s largest Exchange 2010 deployments, we talked about new Store behaviour in Exchange 2010 SP1 that can lead to Exchange forcing an abrupt termination of the server (a blue screen of death with a CRITICAL_OBJECT_TERMINATION).

According to MSDN, a CRITICAL_OBJECT_TERMINATION error bug check “has a value of 0x000000F4. This indicates that a process or thread crucial to system operation has unexpectedly exited or been terminated.” It then goes on to emphasize that “If you have received a blue screen error, or stop code, the computer has shut down abruptly to protect itself from data loss. A hardware device, its driver, or related software might have caused this error.”

Why might Exchange 2010 SP1 force such a dramatic termination of a server? The answer is that new code introduced in SP1 monitors “hanging I/Os”. These I/Os occur when disks are too busy to handle the I/O load generated on the server and can result from storage that is simply not capable of handling the load or in situations where a configuration is not optimum and slows I/O in some conditions. Exchange looks for hanging I/Os because it wants to protect databases against potential loss. Obviously, it’s not good when an I/O has not completed as the I/O may be relevant to essential data. A hanging I/O may never complete as it might be in that charming condition called “hung” – in cyber never-land.

It’s worth noting that Exchange is not the only component that can force a Windows 2008 R2 server into a BSOD as Failover Clustering will also force a server bugcheck under certain conditions that Windows considers to be unrecoverable from without a reboot.

Exchange 2010 SP1 applies a threshold of sixty seconds when it looks for hanging I/Os. In other words, if an I/O has not completed in sixty seconds, it becomes a concern. A failure item is generated and is reported through the crimson (high priority critical incidents) channel to the Active Manager, which then takes whatever action seems appropriate. Hopefully the crisis will pass and the problem I/O will complete to allow Active Manager to cease worrying. However, if the problem persists and the I/O is still hung after four minutes (four times the threshold), Active Manager will force a restart of the server.

Again, the intention is to protect against data loss and that’s a good thing. The problem is the guillotine nature of the action. A BSOD is not a good thing in any administrator’s mind and Exchange provides no evidence to assure the administrator that the action taken was required for good reason. ESE is supposed to write events in the application event log when it encounters hanging I/Os – and any indication of ESE flagging a delayed I/O is worthy of investigation as it may be evidence of a hardware problem that’s about to become worse. However, the administrators that I have spoken to say that they’ve not seen ESE events in the application event log preceding the bugchecks. Microsoft says that the application event log should be updated following detection of the problem and before the failure item is issued to cause the bugcheck. It’s entirely possible that this is the way that events flow in the normal course of events and that perhaps in this situation something happened to cause a failure to log the events. A contact in the Exchange engineering group backs up this feeling by pointing out that the vast majority of problems that lead to a BSOD result from a complete outage in the storage stack so it’s logical (but unsettling) that events cannot be written into the log.

Even more interesting is how Active Manager interprets the criteria for when it forces a restart if multiple hanging I/Os are detected. We’ve already seen the simple condition when a single I/O is hung for four minutes – but if two I/Os are deemed problematic, then the restart will happen after two minutes. The bugcheck is provoked by the MSExchangeRepl process, which terminates Wininit.exe.

My original information, based on observations from some very experienced administrators was that the threshold for Exchange to invoke a BSOD changed in line with the number of hung I/Os. In other words, if four I/Os are in difficulty, the restart happens after a minute. And if your storage system is completely hosed and you have ten hung I/Os caused by something like a buggy storage driver, you would have the opportunity to watch a server reboot after 24 seconds. According to the experience in the field, the real threshold for a server BSOD seemed to be 240 seconds (four minutes) divided by the number of hung I/Os. However, shortly after the original post appeared, the Exchange team got in touch with me to say that the threshold is altered by the number of hung I/Os, but only up to two. As stated above, you can see a BSOD after two minutes if you have multiple hanging I/Os.

It’s absolutely correct that software should include automatic protection to ensure that data is not affected by hardware problems.  It’s also correct that any storage which exhibits so many problematic I/Os that it provokes Active Manager to force a bug check is not a good candidate to support an enterprise application such as Exchange. However, the problem is that a BSOD is a drastic way of cleaning up the hung I/Os that doesn’t leave much evidence behind for the administrator to understand what caused the bug check. It’s kind of like cutting an arm off because it has developed gangrene and immediately burning the offending limb so that doctors can’t see the rotting flesh (OK, I know this is not a nice analogy).

The word is that Microsoft is looking at the situation with a view to making the behaviour more administrator-friendly. This is a good thing and I look forward to seeing the result of their work. I wonder if the upshot will be to replace the BSOD with a big red warning label saying something like:

“Duh! Active Manager thoughtfully crashed your server because your storage failed. Don’t panic! Exchange knows what it is doing and has protected all your data.”

Suitably equipped with skull-and-crossbones, this would be a more interesting error message than a bug check.

– Tony

Want to read more about the changes Microsoft has made to the Information Store in Exchange 2010 SP1? See chapter 7 of Microsoft Exchange Server 2010 Inside Out, also available at Amazon.co.uk or in a Kindle edition. Other e-book formats for the book are available from the O’Reilly web site.

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

Exchange 2010 Maestro training in San Diego, London, and Greenwich, CT

Posted on February 8, 2011 by Tony Redmond

**** Registration now open **** See details below ****

Paul Robichaux and I will be running three more Exchange 2010 Maestro seminars in San Diego, London (UK), and Greenwich, CT in May, June, and October. The site that we use for enrollment isn’t quite ready yet, but you can register to receive more information when all of the details are settled (for example, the cost for the UK event will obvious be in pounds sterling rather than dollars!).

With instructors like this, who needs entertainment (or clowns)?

I’m really happy that we’ve been able to sort out the essential details that are necessary to organize these events. It’s great to be able to do an event in London as many folks in Europe have contacted us to ask us to run an event outside the US. Why London? Well, it’s well connected in terms of air travel and our partner, Penton Communications, has good logistical support there, so we’re confident that we can run a high-quality event.

Some might ask why we’re going to Greenwich. The answer is simple – it’s too expensive to run a relatively small training event in New York City because the hotels ask for huge guarantees for rooms and food. In other words, you have no problems whatsoever booking an event that will have four hundred attendees as you can cope with the hotel demands. But if you try to make a deal for an event that has less than a hundred, the deposit becomes a real concern. In any case, we elected to go a little outside town to keep costs down.

We hope to have the redoubtable Brian Desmond back with us as lab master. Labs posed an interesting challenge for us in our last two events. Paul and I lecture for about 19 hours over the three days, which is a lot of material for attendees to sit through. Labs provide a break from lectures and serve to reinforce the points contained in the lectures, so they’re a good thing and we like having them incorporated in the schedule.

We run all the labs on virtual machines and provide the VMs on a hard drive that attendees connect to their own laptop. This isn’t intended to be an ideal environment for labs as running VMs off a 5400 rpm hard drive is slow (yes, we could provide SSDs but that would add several hundred dollars to the cost). Exchange 2010 needs a few computers before it is fully operational (Active Directory controller, mailbox server, HT/CAS) and it takes time for the VMs to load and have everything ready before any useful work can be done. If come along to the event and don’t bring a heavy-duty 64-bit laptop, you’ll have lots of time to drink coffee while the VMs load.

However, the real purpose of the labs is not to sit in class having a “click along with the instructor” experience. Instead, the labs are designed to be an environment that attendees can take away and reuse when they get back to work. Hopefully, the VMs will be moved onto more reasonable hardware so that performance improves, and afterwards they can be used as a test environment to help prepare the company to migrate to Exchange 2010. In short, if you come along, don’t expect to spend lots of time waiting to be told what to do in the labs. Be prepared to get acquainted with the labs and be ready to reuse them to do some real work when you get back to home base.

In any case, we’re busy making sure that the material is kept up to date to reflect the latest developments in Exchange 2010 and associated products (for instance, since our last events, Microsoft has shipped the update that Outlook 2007 to open archive mailboxes) and to improve the smooth functioning of all aspects of the event. We hope that many will come along to join us in sunny San Diego, historic London, or urban Greenwich…

– Tony

Posted in Exchange, Exchange 2010, Training | Tagged , , , | 1 Comment

Lies, vile lies, and statistics

Posted on February 7, 2011 by Tony Redmond

I was in the middle of a perfectly pleasant briefing on some high availability solutions last week when a slide was presented that asserted that “32% of recovery operations fail”. The statistic apparently came from research done by a market research company that I won’t name here. I’m sure that the research conducted according to the usual norms and that data was collated and assessed with rigor, so I didn’t have a problem about the data source.

My issue was entirely to do with context. Presenting a statistic like this without putting it into context makes the information worse than useless. The logic for including the information on the slide was to emphasize the need for companies to think about the software that they use for disaster recovery. This is a good thing to do as every company should have a well-thought out plan for disaster recovery that is proven to be effective, insofar as this is possible.

However, stating that 32% of all disaster recovery operations fail without informing the listener about essential surrounding information such as the type of recovery operations that failed (complete server, a disk or two, or maybe just the recovery of a file), the sizes of the computers and installations where the failure occurred (I assume that large enterprises have better recovery procedures than perhaps exist in small branch offices), the expertise and experience of the administrator who attempted the recovery, the application and type of data, and the tools used present an incomplete and possibly misleading picture.

Apart from anything else, I also think that CIOs and IT Directors would be under terrific pressure from the business if 32% of recovery operations fail and that administrators who failed in all these attempts would be receiving the proverbial pink slips. You’d imagine that there is a good business reason that justifies the expense and effort of a recovery operation and that the folks who pay for the work wouldn’t be best pleased if their requests for data recovery ended up in failure 32% of the time.

Perhaps I am ultra-sensitive to this kind of thing due to many years of being chastised by editors about leading statements that have appeared in my writing. In particular, I think the editors at Windows IT Pro Magazine do a fine job of reminding authors that they can’t simply scatter statements around articles without providing the evidence to prove to readers that the information is based on a solid base of fact. However, I also think that common sense should sound a loud warning bell when marketing (or technical) personnel representing a company who wants to sell their product put out leading statements backed up by nothing but waffle and hot air.

Low standards in presentations inevitably lead to uninteresting presentations and further compounds the risk of death by PowerPoint. Let’s keep presenters focused by making sure that any important data presented on a slide is backed up by hard data.

– Tony

Posted in Technology | 1 Comment

Exchange 2010 Public Folders: Part 1

Posted on February 4, 2011 by Tony Redmond

This content comes from a chapter removed from my book Microsoft Exchange Server 2010 Inside Out, also available at Amazon.co.uk (including a Kindle edition). For space reasons to keep the book to a reasonable size, the chapter on public folders was removed. This probably made sense as the book should really be focused on all the new technology that’s included in Exchange 2010 rather than the older stuff – and public folders have been around since 1996.

The chapter was supposed to be published as an extra that could be downloaded but that hasn’t happened to date, so here it is. Part 2 is available here and part 3 here. If you like this kind of content about Exchange Server, why not follow me on Twitter so that you receive updates when I post material.

Update: If you’re interested in upgrading to Exchange 2013 and need to migrate some public folders to the modern format (or indeed, to migrate some public folders to Exchange Online in Office 365), then you might like to read my thoughts on the migration process. Then again, you might not!

Enjoy!

Exchange 2010 Public Folders

To me, public folders are the cockroaches of Exchange. They continue to persist despite seemingly being on the edge of extinction several times. Microsoft originally launched public folders as the cornerstone of Exchange’s collaborative capabilities, something that could take on the ability of Lotus Notes to generate end-user applications based on electronic forms. Public folders offer the ability to replicate data so that a copy is close (in network terms) to users, a feature that was tremendously important in the days of expensive and scarce bandwidth. Public folders were the way to share documents and other items across organizations and can be mail-enabled to allow users to send messages to folders, a feature often exploited to allow public folders to serve as the enduring repository for email-based discussion groups.

Many still remember the demos that Microsoft did to prove the capabilities of public folders when they were launched in Exchange 4.0. Playing chess through public folders was my favorite demo as this illustrated the power of electronic forms to gather and display data coupled with the data replication model that used email as its transport. Regretfully, EFD, the electronic forms designer utility, never moved with the times and languished as a 16-bit application that proved less than useless as Exchange evolved.

Nothing remotely similar in terms of shared storage focused on office applications existed in Microsoft’s product lineup until SharePoint 2001 appeared and even though SharePoint has evolved dramatically since then, it still doesn’t deliver quite what public folders do. Public folders are antique, undervalued, and creaking, but they act as a valuable applications platform for many companies and that’s why they are still around. Some companies have hundreds of thousands of folders in their public folder hierarchy, even if they don’t quite know what all the folders are used for, whether they still hold useful information, who created the folders in the first place, and what to do with them in the future.

Public folders and Exchange 2010

Despite their popularity in some quarters, once Microsoft launches into the development cycle for a new version of Exchange, the same question is raised whether this is the version when public folders are finally dispatched to the great byte bucket in the sky. To their credit, Microsoft listened to customers and started to invest a small amount of engineering resource into public folders in Exchange 2007 and have continued on this path in Exchange 2010. Public folders are only required in Exchange 2010 if you:

1.    Have the requirement to support Outlook 2003 clients,which cannot use web-based distribution to access OAB and free/busy data. Outlook 2007 clients are also able to use public folders in this way but Outlook 2010 clients only use web-based distribution to access OAB and free/busy data.

2.    Have applications that are based on public folders. Ten years ago, these applications were reasonably popular but recently they have become a fast-disappearing category as companies have migrated applications to more modern and functional platforms. SharePoint and InfoPath forms are an option that is often considered for the kind of forms-based applications that were deployed on top of public folders.

If you deploy a new Exchange 2010 organization, you’ll be asked by the installation procedure whether any Outlook 2003 clients (or older Entourage clients) exist inside the organization. Outlook Express and other IMAP4 clients are also able to access public folders, but they don’t depend on them for OAB and free/busy. If you need to support these clients, Exchange will create a public folder database to be used for the OAB and free/busy. If not, you’ll never see a public folder database unless you decide to create one. Clients with their mailbox on an Exchange 2010 server can only access public folders if replicas are available in a database hosted by an Exchange 2010 server. If this is not the case, clients will be told that they can’t access public folders because there is no Exchange 2010 public folder server.

It would be unreasonable to expect a dramatic increase in functionality for public folders after a decade of doubt, but it is nice to see that the code is still being maintained. In summary, public folder management is divided between two consoles and EMS:

  • The public folder management console (Figure 1) allows administrative access to the folder hierarchy, including the ability to create new folder replicas on different servers, remove folders, and mail-enable folders. No access is available to the content of public folders through the console as this feature remains the sole preserve of clients. In other words, if you want to see inside a public folder, you have to use a client like Outlook or OWA that can open a folder and view its contents. Outlook is the only client that is able to report how much storage a public folder occupies. The same is true of folder permissions. You can create a new public folder with the console but then need to revert to Outlook or EMS to set permissions.

Figure 1: Exchange 2010 Public Folder Management Console

  • The database management section of EMC allows you to create new public folder databases. Figures 2 and 3 illustrate the two screens of the New Public Folder Database Wizard. After public folder databases are created, you can update their properties such as setting storage limits, replication schedules, and limits for deletion retention and item age. Inside mixed mode organizations that support both Exchange 2007 and 2010 servers, you have to perform public folder management using the Exchange 2010 ESM because of the schema changes made in Active Directory and the Store for Exchange 2010.The situation is slightly more complex when Exchange 2003 servers are present but the same principle exists that you should manage public folder servers using the same version of the management tools as the public folder server. Replication between the different versions of servers is sufficient to keep public folder servers synchronized across the organization.

Figure 2: Creating a new public folder database

Figure 3: Specifying file locations for the new public folder database

  • Exchange 2010 SP1 includes a new Manage Public Folder Settings Wizard that you can use to set user permissions for folders and their sub-folders (Figure 4). Apart from making it much easier to manipulate public folder settings, the wizard is a good learning aid to help administrators become acquainted with the EMS cmdlets that can be used to work with public folders. For instance, to learn the proper syntax for the command to grant a user access to a public folder.

Figure 4: The Manage Public Folder Settings wizard

  • EMS offers a set of cmdlets for public folder management that underpin the features offered by EMC and the public folder management console.

An account must hold the public folder management role before it can perform any public folder management task.

Public folders continue to be organized into two sub-trees within the folder hierarchy:

  • Default public folders (the IPM_Subtree) are those available for population by client applications.
  • System public folders (the non_IPM_Subtree) are not revealed to client applications and are used by Exchange to store system data such as the OAB and free and busy data as well as the organizational forms used by Outlook 2003.

Exchange does not include the content of public folders in its content indexes. You have to use SharePoint if you need to index public folders for search purposes.

If you are used to working with public folders through EMS in Exchange 2007, you need to check any code (especially in scripts) that you have developed for this purpose because Microsoft has made a number of changes in the way that the cmdlets work.

Creating a new public folder database

Exchange 2010 creates a default public folder database if you tell the installation procedure that you need to support Outlook 2003 clients. Because DAGs don’t support public folder databases, you need to create a second database on another server if you want to replicate public folders to ensure some level of high availability. You can create a new public folder database with the New-PublicFolderDatabase cmdlet. This example creates a new public folder database on a specified server and then mounts the new database. Note that you have to tell Exchange where to place the database and transaction logs; this is a difference from Exchange 2007 where you always create a public folder database in a nominated storage group so Exchange can determine the location of the files from the default location of the storage group:

New-PublicFolderDatabase 'PubFolders1' –Server 'ExServer1' -EdbFilePath 'D:\Exchange\PF\PFDatabase.edb'
–LogFolderPath 'D:\Exchange\PF\'
–CircularLoggingEnabled $True
Mount-Database 'PubFolders1'

You can use the Get-PublicFolderDatabase cmdlet to validate that the new database exists:

Get-PublicFolderDatabase –Identity 'PubFolders1' | Format-List

The same cmdlet is used without a parameter to see all the public folder databases that exist within the organization. By default, Exchange does not return the names of public folder databases that reside on Exchange 2003 or 2007 servers, so if you want to see this information, you have to specify the –IncludePreExchange2010 parameter as shown below. The-Status parameter instructs Exchange to return information about the mount and last backup status.

Get-PublicFolderDatabase –IncludePreExchange2010 –Status

Retrieving information about all of the public folder databases in an organization can take some time to complete because of the need to access information from the different servers that host the databases. You can restrict retrieval to a specific server by passing the server name in the –Server parameter.

Get-PublicFolderDatabase –Server 'ExServer1' –Status

Adding new public folders

Now that we have a public folder database, we can populate it with folders using the New-PublicFolder cmdlet. To create a new top-level folder, we use “\” (the root) as the location. For example:

New-PublicFolder –Name 'Technical Information' –Path '\' -Server 'ExServer1'

We can then populate the sub-folders under the top-level folder that we have just created. This example creates a new public folder called Exchange 2010 under the Technical Information top-level public folder and hosts the initial replica on the server called ExServer1. Of course, you don’t have to create new public folders with EMS and many administrators will opt to create folders with Outlook so that they can use a GUI.

New-PublicFolder –Name 'Exchange 2010' –Path '\Technical Information' –Server 'ExServer1'

If you run this command on a mailbox server that has a public folder database, you can omit the server name and Exchange will create the folder in the local database. The root folder (named Technical Information in this case) must exist on the target server. To create the folder at a deeper location in the hierarchy, you pass the complete path to the folder. For example:

New-PublicFolder –Name 'Administration' –Path '\Technical Information\Exchange 2010'-Server 'ExServer1'

Retrieving information about public folders

After you create the public folder, you can check its properties with the Get-PublicFolder cmdlet. As you can see, the complete path has to be stated to allow Exchange to locate the folder:

Get-PublicFolder –Identity '\Technical Information\Exchange 2010\Administration'

A complete list of public folders under the IPM_Subtree is generated by passing the root folder as the path and including the Recurse parameter to force Exchange to traverse the hierarchy and report all folders that it finds. Recurse instructs Exchange to retrieve information about all child folders and their children. Use the –GetChildren parameter instead of –Recurse if you want to just fetch details of the child folders under the path. The two parameters are mutually exclusive. In either case, while you always work with the copy of the public folder hierarchy on the server to which you are connected, this operation can take some time to complete if the public folder hierarchy is large and might not contain any newly created folders if their details are still being replicated. As shown here, you can pipe the list to capture it in a text file.

Get-PublicFolder –Identity '\' –Recurse –ResultSize Unlimited > C:\Temp\PublicFolders.txt

Scanning a large list of folders to find a particular one can be frustrating. You can filter what Exchange returns as follows:

Get-PublicFolder –Identity '\' –Recurse | Where {$_.Name –eq 'Exchange 2010'} | Format-List

HasSubFolders                  : True
HiddenFromAddressListsEnabled  : False
IssueWarningQuota              : unlimited
LocalReplicaAgeLimit           :
MailEnabled                    : False
Name                           : Exchange 2010
ParentPath                     : \Technical Information
PerUserReadStateEnabled        : True
ProhibitPostQuota              :
Replicas                       : {PFDatabase1}
ReplicationSchedule            : {}
RetainDeletedItemsFor          :
UseDatabaseAgeDefaults         : True
UseDatabaseQuotaDefaults       : True
UseDatabaseReplicationSchedule : True
UseDatabaseRetentionDefaults   : True
HasModerator                   : False
Identity                       : \Technical Information\Exchange 2010
OriginatingServer              : ExServer1.contoso.com

We can see that the folder has some sub-folders and we also know the path to the folder, so we can discover the set of sub-folders by running the Get-PublicFolder cmdlet using the folder path and the –Recurse parameter.

Get-PublicFolder –Identity '\Technical Information\Exchange 2010' –Recurse | Select Name, Identity | Format-Table –AutoSize

The same technique can be used to retrieve information about system public folders such as those used to hold OAB and free/busy information.

Get-PublicFolder –Identity '\Non_IPM_Subtree' –Recurse | Select Name, Identity | Format-Table –AutoSize

Two cmdlets are available to retrieve some information about public folder contents. The intention of these cmdlets is that they can be used for basic reporting purposes so that you understand what’s going on within public folders. They are not intended to provide comprehensive reports, although there is no doubt that considerable ingenuity can be exerted to create good looking and interesting reports based on the data generated by these cmdlets.

  • Get-PublicFolderItemStatistics: Provides an insight into the content that exists in a public folder by letting administrators view the item titles, size, and so on.
  • Get-PublicFolderStatistics: Provides summary information about anything from a single folder to all of the public folders known in the hierarchy, including system folders. The summary is provided in alphabetical order and includes name, the number of items in the folder, the size of the items in the folder, and the date and time of the user access to the folder.

The Get-PublicFolderItemStatistics cmdlet is new to Exchange 2010 and lists the basic details of the items in a folder. You cannot see the actual content itself without accessing the folder with a client. For example:

Get-PublicFolderItemStatistics –Identity '\Departments\Finance' | Select Subject, CreationTime, MessageSize | Format-Table –AutoSize

Subject                                         CreationTime          MessageSize
-------                                         ------------          -----------
Finance Planning Sessions – FY10                11/30/2009 6:07:44 AM 9.479 KB (9,707 bytes)
Restricting expenses                            11/30/2009 6:06:45 AM 47.9 KB (49,046 bytes)
Planning for change                             11/30/2009 6:02:20 AM 1.367 MB (1,433,576 bytes)
News about finance changes                      11/30/2009 5:56:07 AM 1.312 KB (1,343 bytes)

Moving to the Get-PublicFolderStatistics cmdlet, if you don’t pass a folder identifier, you get a summary list of all folders in the hierarchy. If you don’t specify the name of a server that hosts a public folder database, Exchange connects to the first public folder database available in the site. The LastUserAccessTime property here is of interest in order to identify public folders that have not been accessed recently by a user because these folders become candidates for deletion if you decide to clean up the public folder structure. It’s unfortunate that many public folders are created, used for a short period, and then rapidly become a repository that is accessed less and less frequently before becoming unwanted orphans that take up valuable database space. If you want to identify public folders that should be deleted, you could sort the output from the Get-PublicFolderStatistics cmdlet by the LastUserAccessTime property so that the folders that have not be accessed recently are at the top of the output. You could then contact the owners of each folder to ask whether the folder should be deleted or kept. The command to generate the report about public folder statistics sorted by last access time is:

Get-PublicFolderStatistics –Server ExServer1 | Sort-Object LastUserAccessTime | Format-Table Name, ItemCount, LastAccessTime –AutoSize

Name                                             ItemCount        LastUserAccessTime
----                                             ---------        --------------
Add-ons                                               34          12/30/2009 3:43:31 AM
Administration                                        112         12/30/2009 3:46:29 AM
Annual Budgets                                        250         12/30/2009 3:58:56 AM
Audits                                                17          12/30/2009 4:01:08 AM
Capital Expenditure                                   52          12/30/2009 4:00:56 AM

Here’s what you might see when you drill down on a specific folder. This output reveals that there is more information available about a folder than shown in the summary view.

Get-PublicFolderStatistics –Identity ‘\Departments\Finance’ | Format-List

ContactCount             : 1
CreationTime             : 11/30/2009 3:57:54 AM
DeletedItemCount         : 12
FolderPath               : Departments\Finance
ItemCount                : 533
LastAccessTime           : 12/30/2009 3:57:54 AM
LastModificationTime     : 12/30/2009 6:58:53 AM
LastUserModificationTime : 12/30/2009 5:22:30 AM
LastUserAccessTime       : 12/30/2009 5:23:30 AM
Name                     : Finance
OwnerCount               : 1
TotalAssociatedItemSize  : 0 B (0 bytes)
TotalDeletedItemSize     : 0 B (0 bytes)
TotalItemSize            : 1.426 MB (1,494,997 bytes)
DatabaseName             : PFDatabase1

We can combine the knowledge we’ve gained from the two examples to do something more useful, such as outputting some data about all folders into a CSV file that we can later manipulate with Excel to understand different aspects of our public folder deployment. For example, we might ask questions such as what the largest folder is, what folders have not been accessed in several months, and what folders are empty? Here’s how to generate the list:

Get-PublicFolderStatistics –Server ExServer1 | Select Name, ItemCount, TotalItemSize, LastUserAccessTime, LastUserModificationTime | Export-CSV 'C:\Temp\Public-Folders.CSV'

Updating public folder properties

Set-PublicFolder is the basic cmdlet used to update the properties of a public folder. Table 1 lists the properties that are most commonly altered.

Property Meaning
Age Limit Sets the age limit for all replicas of a public folder. Folders and their replicas are automatically removed when the age limit expires. Default: Not defined, meaning that folders are persistent until they are removed by an administrator.
IssueWarningQuota Sets the limit at which Exchange issues a warning to public folder owners that the folder is almost full. Default: Unlimited (database default is used)
MaxItemSize Sets the limit of the size of an item that a user can post to a folder. Default: Not set (database default is used)
PerUserReadStateEnabled Tells Exchange to maintain a read state for each user. The read state tracks whether an item has been read by a user. Default: True
ProhibitPostQuota Sets the limit at which users are no longer allowed to post items to a folder. Default: Not set (database default is used).
RetainDeletedItemsFor Sets the retention period for items deleted from a public folder. Default: Not set (database default is used – typically 14 days).

Table 1: Common public folder properties

To see the default limits for a public folder database, select it through EMC, view properties, and then click on the Limits tab (Figure 5).

Figure 5: Viewing public folder database limits

A public folder that is used as a repository for electronic forms is a good instance of when you might need to override the default database storage limits to set a maximum item size that allows the forms to be posted without allowing users to post other items. This example sets a maximum item size of 25KB and sets appropriate storage limits for a folder.

Set-PublicFolder –Identity ‘\Departments\Finance\Forms’ –AgeLimit ‘365.00:00:00’             –UseDatabaseQuotaDefaults $False –MaxItemSize 25KB –ProhibitPostQuota 500MB                 –IssueWarningQuota 465MB –RetainDeletedItemsFor ’90.00:00:00’

Follow Tony @12Knocksinna

Posted in Exchange, Exchange 2010 | Tagged , , | 112 Comments

Super deal: Exchange 2010 Best Practices and Inside Out bundle

Posted on February 1, 2011 by Tony Redmond

Amazon.com has released the Microsoft® Exchange Server 2010 Kit: Microsoft® Exchange Server 2010 Inside Out & Microsoft® Exchange Server 2010 Best Practices books priced at $56.69. This seems like a great price for two books covering Exchange 2010 in more than reasonable depth!

I don’t see similar pricing available in other Amazon country-specific sites – but I suspect that it would be cheaper to buy them from Amazon.com and pay whatever postage and duty is required than to try and get them locally.

– Tony

Posted in Exchange, Exchange 2010, Writing | Tagged , | Leave a comment

Using Outlook 2003 with Exchange 2010

Posted on February 1, 2011 by Tony Redmond

I like Outlook 2003 a lot, mostly because it was the client that liberated users from the tyranny of extended synchronization sessions, often over a spotty dial-up connection, just to collect some new messages. In the bad old days pre-Outlook 2003, receiving a graphic-intense presentation from our friends in marketing was always guaranteed to block Outlook’s pathetic attempts to download new mail and synchronize the Inbox. On the upside, you always knew that you could set off a synchronization session and then go to get coffee in the almost certain knowledge that new mail would be waiting for you when you returned some 15 minutes later… Ah, the versions of Exchange and Outlook prior to the 2003 releases truly operated on a slower pace.

Outlook 2003 was game-changing because it introduced a number of network smarts including drizzle-mode synchronization and on-the-wire compression. Instead of just the “critical” folders being synchronized to the OST, Outlook 2003 was able to create replica copies of every single folder in the mailbox and synchronize them gradually as network conditions allowed. Outgoing messages had their own high-priority thread that got them to the server and generally it all worked very nicely.

Outlook 2003 was also the first version to support RPC-over-HTTP, the feature that is now known as “Outlook Anywhere”. Before this, you had to connect and then create a VPN link to be able to connect Outlook to Exchange and VPNs had the tendency to fail for the most obscure reasons. Being able to piggy-back on any old network connection to collect email was a tremendous step forward for users, even if administrators had to conduct various secret rituals to convince Exchange 2003 to permit RPC-over-HTTP connections. Over the long term, this feature was even more important than enhanced synchronization because it laid the foundation for connections over the Internet to services such as BPOS (and soon, Office 365).

When Microsoft released Exchange 2010 it rapidly became clear that Outlook 2003 had run out of steam. This isn’t altogether surprising given the seven years gap between the two product releases and the growth in server functionality with which clients had to cope. The introduction of retention policies and tags, for instance, requires a lot of additional user interface that clients have to provide.

Initially, Microsoft seemed to treat Outlook 2003 as the ugly sister in the client family – recognized but unappreciated. To their credit, they have done a little better since and have gradually addressed some of the more grievous flaws that the Exchange 2010-Outlook 2003 combination exhibits. A cynic might say that this work has only been done as a result of customer pressure that has forced Microsoft product management to cave in and ship the code. After all, if some of the obvious holes were not plugged, customers who had large populations of Outlook 2003 clients would not be willing to migrate to Exchange 2010. In any case, the following progress has been made:

  • Outlook 2003 depends on UDP (User Datagram Protocol) to notify the user that new messages have arrived. Exchange 2010 dropped support of UDP, which meant that Outlook 2003 had to revert to its backup polling mechanism to detect new messages. The problem is that Outlook then seems to be “slow” at reporting the arrival of new messages. It’s really just a perception issue but if a user has multiple clients, they’ll notice that new messages show up on their BlackBerry or other device faster than in Outlook 2003. Microsoft has committed to fix the problem in Exchange 2010 SP1 RU3, expected in a couple of weeks.
  • Exchange 2010 made encrypted RPCs the default to connect MAPI clients to Exchange via Client Access Servers (CAS). Outlook 2003 does not encrypt RPCs by default (newer clients do), so administrators had to either disable RPC encryption on the CAS or switch it on for all Outlook 2003 clients. Microsoft changed Exchange 2010 SP1 so that the CAS does not enforce RPC encryption by default – but only for newly installed servers.

Other issues exist between Outlook 2003 and Exchange 2010 and you can find a good list on the EHLO blog. One of the more interesting problems is that Exchange 2010 only allows Outlook 2003 to publish two months of future free and busy data. This may not be an issue for your organization, but it is for companies that plan meetings well in advance. If you’re in this category, you can talk to Microsoft support to discover some changes that can be made to increase the publishing window.

Some Exchange 2010 features such as MailTips and archive mailboxes will never be made available to Outlook 2003 clients. However, seeing that Outlook 2003 users have never accessed archive mailboxes nor been nagged about the number of addresses on a message, they will hardly miss the enhanced user interface available to Outlook 2010 clients. Of course, Microsoft recently updated Outlook 2007 to allow access to archive mailboxes but the update doesn’t provide the additional user interface required to features such as MailTips, viewing retention tags, and so on. This underlines the difficulty for engineering groups in touching user interface components when questions such as internationalization and translation increases the cost of the exercise quite dramatically.

Given the current situation, I think that there are three options to work through in a migration scenario from Exchange 2003 to Exchange 2010 with a large population of Outlook 2003:

  1. Keep the client population intact and move to Exchange 2007 instead. Exchange 2007 supports Outlook 2003 “better” than Exchange 2010 does currently. The downside is that you don’t get the chance to use the new functionality of Exchange 2010. Some of the new features, such as the Database Availability Group, are highly desirable. Some, such as MailTips, are useful if less compelling.
  2. Migrate to Exchange 2010 and accept that older clients will have some issues. This is a good solution if you have a long-term plan to deploy newer clients and have the knowledge that you’ll eventually have an integrated environment. For example, you might decide to deploy Exchange 2010 in the next few months followed by a desktop refresh program that provides Windows 7 and Office 2010 to users.
  3. Bite the bullet and migrate to Exchange 2010 and Outlook 2010. Lots of work and difficult to plan and manage in large environments but reasonably attainable in smaller companies.

Of course, there’s always the option to migrate to Office 365 when Microsoft makes it fully available later this year. In this scenario, you will have to deploy Outlook 2010 anyway because Microsoft won’t support Outlook 2003 clients connecting to Office 365.

The final choice will be influenced by many factors. The desire to use the new Outlook 2010 client will be tempered by the difficulty of deploying software to desktops across the organization allied to the cost of the exercise. Management will rightly ask what benefit will be gained from switching over to Outlook 2010 and might opt to stay with older clients unless a solid case can be built to demonstrate real value from the new features. On the other hand, Microsoft won’t support Outlook 2003 for ever…

Just like me, Outlook 2003 has aged. I get away with “salt-and-pepper” hair and a little extra weight, but it’s a fact of technology life that all products have a lifetime and unlike elderly technologists, software doesn’t gain an air of gravitas (perhaps!) as they age. Both of us tend to sag, but that’s not important right now. Outlook 2003 was great when it first appeared and it has rendered sterling service ever since. It’s now reaching – or has reached – the point where Outlook 2003 should be high on the list of suitable clients for Exchange 2010 and no matter how many patch jobs Microsoft does in the future, there is no way that Outlook 2003 will ever reach the heights it once had as an Exchange client.

– Tony

For more information about client options for Exchange 2010, see chapter 10 of Microsoft Exchange Server 2010 Inside Out, also available at Amazon.co.uk. The book is also available in a Kindle edition. Other e-book formats for the book are available from the O’Reilly web site.

Posted in Exchange, Outlook | Tagged , , , , , | 2 Comments

Predictions for 2011: The Exchange Market

Posted on January 26, 2011 by Tony Redmond

On Tuesday, I had an interesting call with Matt Gervais of TechTarget to discuss my views on what will happen for the Exchange market in 2011. Matt is busy talking to some other folks and will share his best assessment of the distilled wisdom of the oracles in an article soon. In the meantime, I thought that I’d make some public predictions, so here are my four top thoughts on what will be important for the Exchange market in 2011.

First, I think that 2011 will be “the year of migration”. The majority of the Exchange installed base still runs Exchange 2003 and extended support of this version terminates in April 2014, which isn’t a long time away when you start to consider all of the work necessary to move users from one platform to another. This fact will cause companies who run Exchange 2003 today to figure out their go-forward plan and begin to make preparations for migration. I doubt that many of these companies will migrate to Exchange 2007 as it doesn’t make sense to move to a  now-ageing version when Exchange 2010 SP1 is available.

I think the choice is binary. They can either migrate to Exchange 2010 or move online to Office 365. The first option will be taken by companies that run complex Exchange environments or have specific reasons to maintain an on-premise deployment. Companies that simply run email are natural candidates to move to Office 365 and let Microsoft do the heavy lifting. I suspect that many small-to-medium companies will select this option as their go-forward plan, especially after Microsoft deploys Office 365 into full production.

Second, I think that 2011 will be a year of refresh. Migrations always provoke some refreshes but Exchange 2010 will provoke more than previous versions. Why? I think refreshes are due for:

  • Servers – any of the older servers running Exchange 2003 are due to be replaced. Brand new servers running Windows 2008 R2 will take up the load and they’ll be equipped with lots of memory to allow Exchange 2010 cache more data than ever before.
  • Storage – the Exchange 2010 I/O profile makes more storage solutions than ever before feasible candidates to support Exchange. Anything from low-end SATA-based storage to high-end SAN will be used to support Exchange 2010.
  • Desktop – Windows 7 is one reason, but Office 2010 is the more pressing influence on Exchange 2010 because you simply don’t get access to all of Exchange 2010’s functionality unless you use Outlook 2010.
  • Third-party products – some will be replaced by functionality in Exchange, others will need to have new versions installed to be compatible with Exchange 2010. I don’t think that many companies who run third-party compliance products such as Symantec Enterprise Vault or HP Integrated Archive will migrate to Exchange 2010’s compliance features for too many reasons to go into here, so that’s one area of third-party action where I suspect to see upgrade action. On the other hand, I suspect that there’ll be quite a few new third-party products appearing to support the new ability of Exchange 2010 SP1 to ingest data from PSTs without using Outlook and allow companies to begin the slow march to eliminate PSTs (the most woeful file structure known to email).

Third, I think that 2011 will be the year when virtualized Exchange becomes mainstream. Virtualized Exchange is not new and both VMware and Hyper-V do a good job of supporting Exchange 2010. The point now is that Microsoft now supports virtualized Exchange and doesn’t treat it as a dirty little secret.

Last, I think 2011 is the year of the Database Availability Group (DAG). Part of all the Exchange 2003 and Exchange 2007 migration projects will be the question of high availability and how to replace all the single copy clusters (SCC) and CCR/SCR deployments that are currently in place. The great thing about the DAG is that it’s native to Exchange and hides the vast majority of the underlying Windows Failover Clustering technology on which it depends. Even better, solutions like the HP E5000 and the inevitable competing offerings that Dell and other server vendors will ship will make it much easier and faster to deploy DAGs through automated deployment assistants and packaged server/storage configurations.

Of course, I have been known to be wrong in the past and I suspect that I will be wrong in the future… but these four predictions are backed up by various collections of tea leaves that I’ve seen after recent cups of tea so I am pretty confident in them.

– Tony

Posted in Exchange, Exchange 2010, Technology | Tagged , , , , , , , , | 3 Comments

First appearance of an Exchange 2010 Messaging Appliance

Posted on January 21, 2011 by Tony Redmond

On January 19, 2011 HP and Microsoft announced the HP E5000 Messaging System for Microsoft Exchange. The name is a mouthful but the important point is the creation of a solution designed to make Exchange 2010 easier to deploy. This product is part of a set of four appliances that HP and Microsoft will ship during 2011 with the second announced as the HP Business Decision Appliance, a SQL solution.

Few would argue that most small-to-medium IT shops struggle to cope with new technology. It’s hard enough to keep applications running to satisfy users while also coping with security updates, service packs, roll-up updates, hot fixes, security threats and new viruses, and all the other demands that arise on a daily basis. With little free time available to review and assess new technology, it’s not surprising that it takes companies a long time to get around to considering an upgrade to a new version of a product like Exchange unless there’s an obvious and clear business requirement or other driver (such as reduced cost).

The problem becomes even more emphasized when a software application goes through a generational change. We saw this happen when Exchange transitioned from its first generation products (Exchange 4.0 to 5.5) to Exchange 2000. The requirement to deploy Windows 2000 and the Active Directory was a real problem for many because the two generations of Exchange were very different. The same is true when the latest generational change occurred with the introduction of Exchange 2007. Although there wasn’t the same fundamental upheaval as we experienced in the changeover from Exchange’s own Directory Service to the Active Directory, the degree of technological difference between Exchange 2003 and Exchange 2007 created a barrier to migration that caused companies to decide to stay with the platform that a) worked and b) they knew well. There was no obvious business benefit to move to Exchange 2007 to compensate for the work required and this is possibly the reason why a very large chunk of the current installed base remains on Exchange 2003 today.

With all this in mind, it makes a huge amount of sense to attempt to help companies move to new technology by making it easier and faster to deploy. Time is money and the amount of hours that can be absorbed in preparation for the deployment of a new version of an application can be staggering. An appliance-type approach that promises to get a server up and running in a couple of hours, correctly configured as if it had been installed by experts from the hardware and software vendors makes a heap of sense.

HP is still about 45 days away from shipping final versions of their appliance.  However, the information available from the solution brief and the press release posted on the HP web site indicate that you’ll be able to buy prepackaged service and storage configurations sized for different user communities (the solution brief mentions 500 to 15,000 mailboxes) that are ready to deploy into an Exchange 2010 organization. The appliance is built around HP c-class ProLiant blade servers and integrated with the HP storage necessary to support “large mailboxes” for the chosen user population.

The actual work of deploying the servers is handled by an HP Quick Deployment Tool that has been designed in conjunction with Microsoft and input from with HP’s own experts who have tons of experience of deploying some of the world’s largest Exchange deployments.

Best of all, the appliance aims to deliver the right server, storage, and network components to create a “DAG in a box”, meaning that you end up with two mailbox servers configured into a Database Availability Group that’s ready to deliver native high availability. This will be popular with any administrator who wants to move from Exchange 2003 and has struggled in the past with the complexity of deploying and operating single-copy Exchange 2003 clusters.

This is the first appliance-type device that I’ve heard of for Exchange 2010 and while the initial details that are available show great promise, there are many questions to be answered. For example, can you use these appliances as building blocks for DAGs that contain more than two mailbox servers? Can you install them into existing DAGs? Can you create stretched DAGs across two datacenters or is the appliance restricted in any way?

I’m looking forward to getting my hands on the HP E5000 to see whether it lives up to the advance billing. If it works as well as I think that it can, the HP E5000 and other similar appliances will eliminate cost and complexity from Exchange 2010 deployments. And while HP may be the first to the appliance party, the appearance of these solutions will encourage other hardware vendors to bring out their own products to create competition and drive innovation in the space and that can’t be a bad thing.

– Tony

Posted in Exchange, Exchange 2010, Technology | Tagged , , , , | 3 Comments

Where’s the 32-bit version of Exchange 2010?

Posted on January 20, 2011 by Tony Redmond

One question that Exchange administrators often ask me is how they can get a 32-bit version of Exchange 2010. Microsoft first moved Exchange to a 64-bit platform in Exchange 2007 but they also issued a 32-bit version to be used for testing purposes. The 32-bit version was also used for training, lab environments, demonstrations, and some limited administration purposes (such as making schema changes to the Active Directory in advance of rolling out Exchange 2007), but Microsoft never intended the 32-bit version to be used in any serious sense.

While it might seem to be reasonably easy to spin off a 32-bit version alongside the normal 64-bit version during the engineering build process, making this software available creates some cost for Microsoft, not to mention the technical complexity to maintain the build integrity such as making sure that bugs aren’t introduced by having to create versions for two platforms. You can argue that Microsoft gains a lot from the 32-bit version by allowing people to become more familiar with Exchange because they can install it on a virtual machine running on a laptop. The same environment can be used to test Exchange, to demonstrate it to new customers, or even to validate statements that appear in books. All of these activities are valid and important but Microsoft decided not to go ahead with any further 32-bit builds during the Exchange 2010 beta cycle. This decision was taken over 18 months ago so it’s surprising that people are still asking… or maybe not!

Microsoft’s logic is that they needed to make a 32-bit version available for Exchange 2007 because it was the first version to move to 64-bit and companies needed help to make the transition. They also point out that generating multiple versions of Exchange consumes a considerable amount of engineering resource that they prefer to use to develop new functionality and fix bugs in a drive for a more functional and higher-quality product. To put this situation into context, Exchange 2010 consists of many million lines of managed code (mostly C#). Even with fast systems, compilation of Exchange’s source code still takes hours. Even then, all you have is a version that may contain bugs that have been introduced by new code checked in since the last build, so before the version is released, Microsoft puts it through a huge battery of regression and functionality tests to ensure that the code is solid.

During development, Microsoft builds a new version of Exchange daily following a cycle of check-in, compilation, and testing. The test suite is exacting because customers deploy Exchange in wildly different circumstances, so Microsoft has to ensure that Exchange works in a variety of scenarios. A test of a single bug fix therefore has to be run multiple times to test the code against all of the scenarios where Microsoft expects Exchange to function – virtualized and “real” servers, in a DAG or standalone, on a server with one role or one that supports multiple roles, potentially against different versions of the Windows O/S, and so on.

With such a large code base, it should come as no surprise that the Exchange development group fixes hundreds of bugs weekly. Many of these bugs are small (for instance, a spelling mistake in a help file or an inconsistency in translation in one of the language versions) while others are more fundamental. All of the fixes have to go through regression testing to make sure that they don’t break something else and as the end of the development cycle approaches, increasing focus goes onto fixing the must-fix bugs to ensure that Exchange meets its goals for features and quality. Given all of this activity and cost (financial and people), it’s not surprising that the Exchange development group wanted to stop work on the 32-bit version. It’s also worth noting that the same discussion is going on with every Microsoft engineering group with the result that products such as SharePoint 2010 is only available as a 64-bit release running on Windows 2008 with a dependency on the 64-bit version of SQL Server 2008 or SQL Server 2005.

The bottom line is that Exchange 2010 is a pure 64-bit environment. There is a consequential need to invest in 64-bit hardware for use in labs, training centers, or other demonstration and testing activities as well as to perform management of Exchange 2010 servers. Not everyone runs 64-bit laptops or workstations, so there’s obviously some cost involved to upgrade hardware and software to create a suitable environment based on virtualized servers (Hyper-V or VMware) or terminal services.

Depending on their BIOS, many current 32-bit PCs can support virtualized 64-bit guest systems. For example, VMware workstation running on Windows Vista is capable of supporting an Active Directory domain controller and two Exchange 2010 servers running on Windows 2008 R2. Things get slow when you run two or more virtual servers as 32-bit OS cannot address more than 3GB of memory and laptops are further handicapped by their slow disks. If you want to run virtualized Exchange on a laptop for development or test purposes, you should use the 64-bit version of Vista or Windows 7 equipped with at least 6GB of memory and a fast external drive (such as an SSD drive). My experience is that modern laptops configured in this way deliver a very usable platform.

If you want to run the Exchange 2010 version of the management console, you’ll need to use a 64-bit workstation running Vista SP2 or Windows 7. The workstation has to be joined to a domain, but not necessarily the domain where Exchange 2010 exists, as Kerberos is used for authentication and to encrypt the remote PowerShell channel used for management operations. And of course, the option still exists to manage Exchange 2010 over RDP using the Remote Desktop Connection application that’s built into Windows XP, Windows Vista, and Windows 7. This application allows you to connect to any Exchange or other server in your organization and manage it as long as you can create a connection to your network. I’ve managed Exchange servers with RDP over varying connections around the world, including using a VPN connection established using the Internet Sharing application on a Windows Mobile phone when travelling on a train through the Netherlands.

No further 32-bit builds of Exchange will appear and the future is entirely 64-bit, until of course the time comes to upgrade to a 128-bit, 256-bit, or whatever new number of bits future hardware and software platforms require.

– Tony

Posted in Exchange, Exchange 2010 | Tagged , | 2 Comments