Anything posted on the Internet has a reasonably long half-life, a fact that I was reminded of when I researched some information about the Windows LocalSystem account and discovered an article that I wrote for Windows IT Pro magazine about Exchange 2000.

In a nutshell, the article discussed a major change that Microsoft made in Exchange 2000 to replace the “service account” as the basis for running the set of Exchange services (such as the Information Store and Directory Services) that collectively form the product. The first generation of Exchange (versions 4.0 through 5.5) ran on Windows NT 3.51 and Windows NT 4.0 and didn’t use the Active Directory. It’s fair to say that these versions were not really designed to cope with the needs of major enterprises and reflected some of the thinking that found its way into PC LAN-type products at the time. When you installed Exchange, you created a service account, a highly privileged account that Exchange used to run its services. The service account was often called “ADMIN”. All manner of things could go wrong with this account that wreaked havoc on Exchange, including the inadvertent changing of the service account’s password, something that was guaranteed to bring everything to a crashing halt followed by some pretty pointed inquiries as to who changed the ****ing password!

Looking back, we now realize just what a fundamental transformation occurred in Exchange 2000 as Microsoft introduced many of the structures that still persist today and allow Exchange to cope with the needs of the largest enterprise, or indeed, very large hosted environments. Replacing Exchange’s own X.500-based Directory Services with Active Directory is often cited as the biggest change, but I think that moving to use LocalSystem as the basis for running the suite of Exchange services is possibly equally important. Just have a look at the set of services that run on an Exchange 2010 server today and reflect on the fact that all run under LocalSystem.

Why would I even think about LocalSystem at this point? After all, it’s been around since Exchange 2000 and any of the initial glitches have been eradicated over Exchange 2000, 2003, 2007, and 2010 and all the various service packs and fixes that Microsoft has released since 1999.

My interest was reignited by a discussion about the Microsoft Exchange Mailbox Replication Service (MRS). Exchange 2010 SP1 extended the functionality of MRS to include the ability to process mailbox import and export requests. These requests are created with the New-MailboxImportRequest and New-MailboxExportRequest cmdlets and these cmdlets either read from (import) or write to (export) PST files held in a network file share. For more details, see my Windows IT Pro article on the topic.

Log-on properties of the Mailbox Replication Service

As you can see from the screen shot, MRS runs under the context of the LocalSystem account. Getting back to our story, I have been pretty public about my dislike of PST files as I regard the file format to be tremendously insecure. Any MAPI client can open a PST file and even if you “protect”a PST with a password, anyone who wants to get into the file can do so easily with a password cracker utility. With this fact in mind it is clear that the PSTs used for import and export operations must be protected against people who might browse network shares looking for interesting data. At the same time, the network share has to be accessible to MRS.

The advice given to administrators is that the network share should be locked down and read-write access allowed to the Exchange Trusted Subsystem. This is usually sufficient to allow MRS to manipulate the PSTs – unless MRS is running on the same server that hosts the network share, in which case MRS runs under the context of LocalSystem, and if the network share is not accessible to LocalSystem, you’ll see a file access error when you attempt to create the new import or export request. The error message will be similar to this:

Unable to open PST file '\\ExServer1\Imports\Test1.pst'. Error details: Access to the path '\\ExServer1\Imports\Test1.pst' is denied.; Microsoft.Exchange.MailboxReplicationService.RemotePermanentException: Access to the path '\\ExServer1\Imports\Test1.pst' is denied.

The solution is to make sure that the network share is accessible by the SYSTEM account as this will allow MRS to open the files using its LocalSystem credentials.

I must admit that I didn’t meet this problem myself. It came about in a frustrating manner for a colleague who found that attempts to create some MRS import requests were successful while others failed. In figuring out what happened, it’s important to realize that MRS runs on every Client Access Server and that multiple MRS instances may operate within an Active Directory site. The failed MRS imports were those for the MRS instance running on the same server that hosted the network share while the successful imports were processed by an MRS instance running on a different server. You would never see this problem if you host PSTs in a network share on a dedicated file share server that didn’t run the Exchange 2010 CAS role, but you could in other circumstances – unless you make sure that LocalSystem has read-write access to the network share.

– Tony

Need some more information about Exchange 2010 SP1? If so, check out 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. Alternatively, come along to the Exchange 2010 Maestro Seminars that will run in San Diego (May), London (June), and Greenwich, CT (October).