Exchange Server 2007

You've probably heard of MFCMAPI, a very useful program in the hands of any administrator who wants to learn just what's stored in an Exchange mailbox. MRMAPI is less well known, but it is also pretty useful for other reasons....More

At last, the chocks have been released and the runway is almost clear for Exchange 2013 deployment. The missing places that have stopped existing customers introducing Exchange 2013 into their environment have been provided with the release of: Exchange 2010 SP3 Exchange 2007 SP3 RU10 Basically, these are the versions of Exchange that understand how to play together nicely with Exchange 2013 so that, for instance, an incoming client connection can be proxied by an Exchange 2013 CAS to an Exchange 2010 mailbox server. However, the final piece of the puzzle will slot into place when Microsoft releases Exchange 2013 CU1 (cumulative update #1) in Q1 2013, in line with their new servicing strategy for Exchange 2013 announced last week. Given that we are mid-way through Q1, you can assume that CU1 is on the way very soon. Exchange 2010 SP3 also supports Windows Server 2012, which I think will be the most popular operating system for Exchange 2013 deployment, and it is required to co-exist in a hybrid environment alongside the upcoming Wave 15 refresh for Office 365, when “the service” gets to run datacenter versions of Exchange 2013, Lync 2013, and SharePoint 2013....More

A reasonable amount of confusion appears to have arisen after Microsoft re-released the latest roll-up updates for Exchange 2007 SP3 and Exchange 2010 SP1 and SP2 on October 9. Only one piece of additional functionality is included in the new software (KB2756987, a fix that ensures the correct search results are provided to Outlook 2010 and Outlook 2013 clients), so it’s not the case that Microsoft suddenly discovered some lingering bug or horrible problem that they had distributed in error in the original releases. Instead, as we find out in the Microsoft Security and Defense blog, the root cause that forced the rerelease is a “clerical error made in code-signing” that  meant that the digital signatures applied to the software will expire prematurely. Once a digital signature expires, the software is no longer trusted by the WinVerifyTrust function used by Windows to validate software. The blog isn’t explicit as to exactly when the signature expires, preferring to say that “it occurs in the next few months”. The recommendation from Microsoft’s security team is as follows: “We encourage all customers to apply the re-released, re-signed security updates as they become available.  As an additional defense-in-depth measure, we recommend that customers also apply the updated WinVerifyTrust package which serves as an effective way for Windows and Microsoft applications to extend the validity period of these packages beyond the premature expiration date. ...More

Because we’re all skilled computer professionals who have carefully considered a suitable computer naming convention before deploying any server into production, I can’t think of good reasons why anyone would ever want to rename an Exchange server. On the other hand, I can think of some pretty bad reasons for wanting to rename a server such as wishing to update all names following a corporate merger or as part of a rebranding exercise launched by the marketing department. Of course, this kind of exercise cheerfully ignores the basic logic that few users care what their server is called and fewer probably know how to find out. Administrators do care because of the naming convention that is in use to identify servers and the role that they play within an organization. Some questions have recently been asked on the topic so I thought it worth discussing here. If backed into a corner by the unreasonable demand to rename a server, the first ploy that should be adopted is the standard response “it’s unsupported by Microsoft”. In this case it’s actually true and Microsoft support is most unlikely to be happy with you if you call in to report that things went horribly wrong when you attempted to rename a server. However, aside for the directive that you must not change the server name after installing an Edge server that’s buried in a TechNet article, there is little authoritative commentary on the topic, so here’s why you shouldn’t even consider a renaming exercise. The first thing to realize is that Active Directory is liberally populated with references to an Exchange server name. Both the distinguished name (DN) and the visible server name can be found. The basic location to start looking is in the Servers container in the famous Exchange Administrative Group (FYDIBOHF23SPDLT) container (much beloved of those interested in playing Exchange trivial pursuit). You’ll need to navigate to Services, then Microsoft Exchange, and then the name of your organization within the...More