Blog (at) Mreza.Info

As many of you probably know, Service Pack 2 for Exchange Server 2007 is one of the prerequisites for introducing Exchange Server 2010 into existing Exchange organization.

Beside many fixes, Service Pack 2 for Exchange Server 2007 also includes some cool new features:

• Enhanced Auditing: New Exchange auditing events and audit log repository enable Exchange administrators to more easily audit the activities occurring on their Exchange servers. It allows the right balance of granularity, performance, and easy access to audited events via a dedicated audit log repository. This simplifies the auditing process and makes review of audited events easier by segregating audited events in a dedicated location.
• Exchange Volume Snapshot Backup Functionality: A new backup plug-in has been added to the product that will enable customers to create Exchange backups when a backup is invoked through the Windows Server 2008 Backup tool. Exchange Server 2007 didn't have this capability on Windows Server 2008 and additional solutions were required to perform this task.
• Dynamic Active Directory Schema Update and Validation: The dynamic AD schema update and validation feature allows for future schema updates to be dynamic deployed as well as proactively preventing conflicts whenever a new property is added to the AD schema. Once this capability is deployed it will enable easier management of future schema updates and will prevent support issues when adding properties that don't exist in the AD schema.
• Public Folder Quota Management: SP2 enables a consistent way to manage quotas by improving the current PowerShell cmdlets to perform quota management tasks.
• Centralized Organizational Settings: SP2 introduces new PowerShell option that enable centralized management of many of the Exchange organization settings.
• Named Properties cmdlets: SP2 enables Exchange administrators to monitor their named property usage per database.
• New User Interface for Managing Diagnostic Logging: SP2 enables Exchange administrators to easily configure and manage diagnostic logging from within the Exchange Management Console.

Update your server(s)!

I strongly recommend that you install latest Service Packs and hotfixes for your operating system and installed software. Please note that Exchange Server 2007 (SP2) is only supported on Windows Server 2003, Windows Server 2003 R2 and on Windows Server 2008. Windows Server 2008 R2 is not supported!

Windows Installer 4.5

You need to deploy Windows Installer 4.5 on all target Exchange Server 2007 servers prior installing Service Pack 2.

Download Windows Installer 4.5 for Windows Server 2003 SP1, Windows Vista SP1 and Windows Server 2008 RTM from Microsoft Download:

Download: Windows Installer 4.5 Redistributable

Please note that Windows Installer 4.5 is already included in Windows Server 2008 SP2 and Windows Vista SP2.

Backup Active Directory and Exchange!

Please backup Active Directory and Exchange (especially Databases) before Active Directory preparation and Exchange Server 2007 SP1 installation. You should consider reading my previous blog post named Importance of good backups.

Prepare Active Directory

Not all steps are necessary in simple Active Directory setup (single domain forest). So here are necessary steps to prepare Active Directory for Exchange Server 2007 Service Pack 2. The advantage of running steps separately is that you can use account which has minimum permissions necessary for task.

• Run  setup /PrepareSchema – You need to run this with domain account that is member of Schema Admins and Enterprise Admins security groups. Make sure that you run this commands from server that is in the same Active Directory Site as Schema Master DC. (Note: You must not run this command in a forest in which you do not plan to run setup /PrepareAD. If you do, the forest will be configured incorrectly, and you will not be able to read some attributes on user objects.).
• Run setup /PrepareAD - You need to run this with domain account that is member of Enterprise Admins security group. Make sure that you run this commands from server that is in the same Active Directory Site as Schema Master DC. In order to support the new Role Based Access Control (RBAC) model in Exchange Server 2010, a new security group is created inside Microsoft Exchange Security Groups OU named Exchange Trusted Subsystem.
  
  
  
• Run setup /PrepareDomain to prepare local domain, run setup /PrepareDomain:exlab.exchange.pri to prepare specific domain, run setup /PrepareAllDomains to prepare all domains in forest. Please note that /PrepareAD prepares current (local) domain during process. If you have single domain Active Directory forrest, running /PrepareDomain is not needed. PrepareDomain in Exchange Server 2007 SP2 does not include ACEs introduced by Exchange Server 2010.

After you run each command, you should wait for the changes to replicate across your Exchange Organization. It can take a while in large Active Directory site topology. You can always force replication via Active Directory Sites and Services MMC.

How do you verify successful preparation of Active Directory?

Setup.com /PrepareSchema sets value of rangeUpper attribute of ms-Exch-Schema-Version-Pt to 14622 after successful finish.

Setup.com /PrepareAD sets value of objectVersion attribute of <Organization Name> container to 11222 after successful finish.

Installation order

There is nothing specific in the installation order of Exchange Server 2007 Service Pack 2. You should stick with standard installation order for Exchange Server 2007:

1. Upgrade all Client Access Servers
2. Upgrade all HUB Transport Servers
3. Upgrade all EDGE Transport Servers (can be upgraded later but not before HUB Transport Servers)
4. Upgrade all Mailbox Servers
5. Upgrade all Unified Messaging Servers

In multi site environment upgrade site by site in the above order (not for example all Client Access Server across multiple sites! and than next role). Upgrade internet facing site(s) first.

Links:

• Download Exchange Server 2007 Service Pack 2

We all know that Microsoft products such as Exchange Server 2007, SQL 2005 x64 can really benefit from x64 platform. But what about Active Directory? Similar to the limitations of Exchange Server 2003, Active Directory suffers from the 2GB virtual memory limit of 32bit operating systems. That`s not a problem for small AD deployments but it can be a real issue for large deployments with a LOT of objects. With large number of object it gets difficult to cache the Active Directory database and authentication requests and queries leads to excessive paging and a slowdown in performance.

So if you are planning or working with a large Active Directory deployments than go for x64 platform. Especially now when prices for 32 and 64bit platform are almost the same. [Y]

Let me quickly try to explain about 2GB memory limit in 32bit operating systems.  You probably all heard about the Windows 4GB memory limit. When talking about performance tuning and server sizing, people are quick to mention the fact that that an application on an 32bit Windows system can only access 4GB of memory.

What does that really means?

A 32 bit processor uses 32 bits to refer to the location of each byte of memory. 2^32 = 4.2 billion. That means a memory address that`s 32 bits long can only refer to 4.2 billion unique locations in memory (that`s 4GB of memory). (Source: Wikipedia)

In the 32bit Windows each application has its own »virtual« 4GB memory space. This 4GB memory space is distributed into two parts, with 2GB dedicated for kernel and 2GB for application usage. Each application has its own 2GB, but all have to share the same 2GB kernel space. Using the /3GB boot.ini switch is even worse in some cases (Terminal Server for example). This switch changes the amount of memory for application and kernel environment. It gives 3GB of memory for application environment and »only« 1GB of memory for kernel. But if you are using /3GB boot.ini switch for SQL Servers you can gain performance since it`s a memory-intensive application (and not kernel).

There is a difference when systems are booted using /PAE switch. Physical Address Extension (PAE) is an Intel provided memory address extension that enables support of up to 64GB of physical memory for application. PAE allows the most recent IA-32 processors to expand the number of bits that can be used to address physical memory from 32bits to 36bits trough support in the host operating system for applications using Address Windowing Extension (AWE) application programming interface (API). AWE enables programs to reserve physical memory as non-paged memory and then to dynamically map portions of the non-paged memory to the program`s working set of memory. This process enables memory-intensive programs, such as I already mentioned before (SQL – databases), to reserve large amounts of physical for data without having to be paged in and out of a paging file for usage. Instead the data is swapped in and out of the working set and reserved memory is in excess of the 4GB range.  Additionally, the range of memory in excess of 4GB is exposed to the memory manager and the AWE functions by PAE. Without PAE, AWE cannot reserve memory in excess of 4GB.