Category Archives: Exchange 2010

Exchange 2010 SP1 Language Pack Bundle

0
Filed under Exchange 2010
This download contains the most recently updated language packs for Exchange 2010. The language bundle includes all packs for all supported languages.
 
This download is available to customers who would like to install the most recent languages packs for Exchange 2010. This bundle does not include language packs for Unified Messaging.
 
Download here
 

Exchange 2010 RTM schema prep fails when Exchange 2007 SP3 is installed

0
Filed under Exchange 2010

According to Technet you should be able to install Exchange 2010 in an environment where Exchange 2007 is installed. But when running the setup.com /ps to extend the schema for Exchange, the following error message may be displayed:

 

 Schema

 

This error appears if you have extended the schema for Exchange 2007 SP3, because the schema version for SP3 is higher than the one for Exchange 2010 RTM.

Luckily Exchange 2010 SP1 has been released. SP1 introduces a higher schema version that 2007 SP3 and thus solves the problem.

 

Below an overview of the Exchange versions and which schema version they use:

Exchange

Forest (rangeUpper)

Forest (objectVersion)

Domain (objectVersion)

2000 RTM

4397

N/A

4406

2000 SP3

4406

N/A

4406

2003 RTM

6870

6903

6936

2003 SP2

6870

6903

6936

2007 RTM

10637

10666

10628

2007 SP1

11116

11221

11221

2007 SP2

14622

11222

11221

2007 SP3

14625

11222

11221

2010 RTM

14622

12640

12639

2010 SP1

14726

13214

13040

 

 

Exchange 2010 SP1 released

0
Filed under Exchange 2010

Overview

Microsoft Exchange Server 2010 helps IT Professionals achieve new levels of reliability with greater flexibility, enhanced user experiences, and increased protection for business communications.
  • Flexible and reliable – Exchange Server 2010 gives you the flexibility to tailor your deployment based on your company’s unique needs and a simplified way to keep e-mail continuously available for your users.
  • Anywhere access – Exchange Server 2010 helps your users get more done by giving them the freedom to securely access all their communications – e-mail, voice mail, instant messaging, and more – from virtually any platform, Web browser, or device.
  • Protection and compliance – Exchange Server 2010 delivers integrated information loss prevention, and compliance tools aimed at helping you simplify the process of protecting your company’s communications and meeting regulatory requirements.

Release notes

Download here

Exchange 2010 SP1: Database Integrity checking

0
Filed under Exchange 2010

Since the earliest versions of Exchange Server, the Information Store Integrity Checker (ISInteg) has offered Exchange administrators a way to check mailbox and public folder database integrity. ISInteg checks and fixes Exchange database errors that may prevent the database from mounting, prevent the user from logging on or from receiving, opening or deleting email. Curious to know what changes are coming to ISInteg in Exchange 2010 SP1? Let’s take a look.

In Exchange 2010 SP1, ISInteg is no longer a standalone program.

The functionality provided by the ISInteg tool has been rolled into two new Exchange Management Shell cmdlets:

  • New-MailboxRepairRequest
  • New-PublicFolderDatabaseRepairRequest

Note: Like other Shell cmdlets, these are subject to Role-Based Access Control (RBAC) scoping restrictions. For details, see Understanding Management Role Scopes.

Cool Features

These new ISInteg cmdlets come with some cool new functionality!

  • The cmdlets work with the database mounted. It’s no longer required to unmount the database to perform an integrity check or fix database errors.
  • You can repair logical corruption at the mailbox level.
  • You can fix corrupt search folders.
  • You can fix the Provisional Fid.
  • You can fix Aggregate Counts.

ISInteg can now work at the database or mailbox level

How does it do that? Well, the new schema in Exchange 2010 effectively partitions the database by mailbox. So the top problems fixed by ISInteg are now mostly limited to the affected mailboxes only. Previous versions of ISInteg required the database to be offline while validation and fixing are in progress. In Exchange 2010 SP1, the ability to do these checks at the mailbox level removes the need to dismount the database. It is actually required to have ISInteg operate against an online database!

New-MailboxRepairRequest

The New-MailboxRepairRequest cmdlet detects and fixes the following types of mailbox corruptions:

  • Search folder corruptions (SearchFolder): Repair tasks now look for all folders named in ptagSearchBacklinks, ptagSearchFIDs, and ptagRecursiveSearchFIDs and verifies that each folder exists. If the folder no longer exists, then it will remove that folder from the list.
  • Aggregate counts on folders that aren’t reflecting correct values (AggregateCounts): Repair tasks tally all messages in a folder and keep a running total of various counts and sizes. Once the iteration is complete, it will verify the computed counts against the persisted counts on the Folders table record for the folder. If there is a discrepancy, it will update the persisted counts to reflect the computed counts.
  • Views on folders that aren’t returning correct contents (FolderView): Repair tasks will iterate over all views for a folder and for each one, bring the view fully up to date and then reconstruct a temp copy. If there is a discrepancy between the existing view and the contents of the temp table, it will delete the view so it can be rebuilt from scratch the next time it is requested.
  • Provisioned folders that are incorrectly pointing into unprovisioned parent folders (ProvisionedFolder): Repair tasks can fix Provisioned folders incorrectly pointing into unprovisioned parents or vice versa.

Syntax

New-MailboxRepairRequest -Mailbox <MailboxIdParameter> -CorruptionType <MailboxStoreCorruptionType[]> [-Archive <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]]

New-MailboxRepairRequest -Database <DatabaseIdParameter> -CorruptionType <MailboxStoreCorruptionType[]> [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]]

Parameters

  • Database, Mailbox and Archive: You can repair an entire mailbox database or a specified mailbox by specifying either the Database or the Mailbox parameter. You can’t use both. To repair the archive mailbox for the specified user, use the Archive switch.
  • CorruptionType: (at least 1 required) you are already familiar with, we discussed them above:
    • SearchFolder
    • AggregateCounts
    • ProvisionedFolder
    • FolderView

    You can run a repair task with multiple parameters if you separate them with a comma (as shown in the Examples section below).

  • DetectOnly: (Optional) The DetectOnly switch secifies that you want this command to report errors, but not fix them. You don’t have to specify a value with this switch.
  • Other Optional Parameters: This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer and OutVariable. For more information, type “get-help about_commonparameters”.

      New-PublicFolderDatabaseRepairRequest

      The New-PublicFolderDatabaseRepairRequest cmdlet detects and fixes Public Folder replication state problems.

      Syntax

      New-PublicFolderDatabaseRepairRequest -Database <DatabaseIdParameter> -CorruptionType <PublicFolderDatabaseCorruptionType[]> [-Confirm [<SwitchParameter>]] [-DetectOnly <SwitchParameter>] [-DomainController <Fqdn>] [-WhatIf [<SwitchParameter>]]

      Parameters

      • Database: (required) Specifies the Public Folder database on which you will run this command. You can use one of the following values:
        • GUID of the database
        • Database name
      • CorruptionType: (required) Pretty easy, there’s only one value.
        • ReplState
      • DetectOnly: (optional) Specifies that you want this command to report errors, but not fix them. You don’t have to specify a value with this parameter.
      • Other Optional Parameters: This cmdlet supports the common parameters: Verbose, Debug, ErrorAction, ErrorVariable, WarningAction, WarningVariable, OutBuffer and OutVariable. For more information, type “get-help about_commonparameters”.

        Examples

        New-MailboxRepairRequest -Mailbox administrator@contoso.com -CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView

        New-MailboxRepairRequest -Mailbox administrator -CorruptionType SearchFolder, AggregateCounts, ProvisionedFolder, FolderView -WhatIf

        New-PublicFolderDatabaseRepairRequest -Database PFD01 -CorruptionType ReplState -DetectOnly

        Some additional examples are provided in the cmdlet help. You can retrieve them using the following commands, or refer to New-MailboxRepairRequest and New-PublicFolderDatabaseRepairRequest cmdlet reference:

        Get-help New-MailboxRepairRequest -examples
        Get-help New-PublicFolderDatabaseRepairRequest -examples

        I recommend that you get to know the cmdlets by using the cmdlet reference docs, or by using the following commands to retrieve detailed help from the shell:

        Get-help New-MailboxRepairRequest -detailed (or -full)
        Get-help New-PublicFolderDatabaseRepairRequest -detailed (or -full)

        Event Reporting

        After submitting the Mailbox or Public Folder repair request, you can monitor its progress with the Event Viewer. That’s right, no more text logs to weed through. The events are logged under the MSExchangeIS Mailbox Store source.

        The following event IDs will be logged for repair requests:

        • 10047 A mailbox-level repair request started
        • 10064 A Public Folder repair request started
        • 10048 The repair request successfully completed.
        • 10050 The mailbox repair request task skipped a mailbox .
        • 10059 A database-level repair request started.
        • 10062 Corruption was detected.


        Figure 1: Mailbox or Public Folder database repair request events are logged in the Application event log

        Note: the repair events will only show up on the mailbox server where the mailbox or Public Folder is located.

        This is very important to remember. Just because you fired off a repair task on a mailbox server does not mean the events will show up on that server. The repair task will be run on the database where the mailbox itself is, and the events will be in the event log on that mailbox server and that server alone.

        Things to remember:

        • Only 1 active repair task is permitted to be running per server if the active task is a database level repair.
        • Only 100 mailbox level active repair tasks are permitted to be running at once per server.
        • There is no -Server parameter to do all databases or mailboxes on a server.
        • The repair task dies on database dismount or store stop/crash.
        • The only way to stop a repair is to stop the store or dismount the database.
        • Mailbox access will be disrupted for the mailbox that is being repaired.
        • Repair for a mailbox will skip a mailbox if it has been quarantined.
        • Repair will cause a move-mailbox operation to be delayed until the repair is finished

         

        Source: http://msexchangeteam.com/archive/2010/08/23/455899.aspx

        Operating a Global Messaging Environment by Using Exchange Server 2010 paper from MS IT Showcase

        0
        Filed under Exchange 2010

        Summary:

        Enterprise IT organizations, including the Microsoft Information Technology (Microsoft IT) group, deal with service level agreements (SLAs) and power users accustomed to high levels of performance, availability, and responsiveness. The 180,000-plus users at Microsoft send over 15 million internal e-mail messages a day from more than 150 offices worldwide, as well as from home and while on the road. At Microsoft, many business-critical communication processes depend on the availability of messaging services provided through Microsoft® Exchange Server 2010.

        Managing the complex Microsoft IT infrastructure is a team effort that involves many different groups, such as the Datacenter team, the Network Infrastructure team, the Active Directory® team, and the Exchange Messaging team. Overall, Microsoft IT manages two distinct environments: a pre-release production environment to test new product versions and upgrades prior to their release to manufacturing (RTM) and a corporate production environment to provide IT services to Microsoft users. Within these environments, the Microsoft IT Exchange Messaging team handles all Exchange-related operation, management, administration, and process optimization. In that role, the Exchange Messaging team works with many other peer teams at Microsoft IT, sharing its operations and process optimization expertise to help those teams implement efficient and reliable operations processes.

        The Messaging Operations group within the Exchange Management team must meet several reliability, availability, and performance targets (such as 99.99 percent availability of Exchange services). To meet these targets, the Messaging Operations group makes use of industry-standard methodologies such as Microsoft Operations Framework (MOF), Microsoft Solutions Framework (MSF), and Information Technology Infrastructure Library (ITIL). For example, the operations model that the Messaging Operations group implemented based on the ITIL framework relies on structured incident management, problem handling, configuration management, and change control processes. These processes enable the Messaging Operations group to capitalize on Exchange Server 2010 administrative features, such as the Exchange Management Console (EMC), to reduce operations costs and ensure efficiencies.

        The key to success in daily operations is the right combination of technology, people, and processes. For example, the Messaging Operations group uses technical tools, such as the built-in product features of Exchange Server 2010 and Microsoft System Center Operations Manager, combined with a clear team structure and work processes that facilitate collaboration. Built-in product features of Exchange Server 2010, such as Database Availability Groups (DAGs), help the Messaging Operations group meet 99.99 percent availability and performance targets. New tools and software features, and optimization opportunities gained through customer feedback, enable the Messaging Operations group to analyze and implement changes when necessary to keep pace with the innovative and agile business landscape at Microsoft.

        This white paper is for business decision makers, technical decision makers, and operations managers. It assumes that the reader has a working knowledge of Microsoft Windows Server® 2008, Active Directory, Exchange Server 2010, and Microsoft System Center Operations Manager. Because many of the principles and procedures discussed in this paper are based on standard operations methodologies, a high-level understanding of the MOF, MSF, and ITIL models is also helpful.

        http://technet.microsoft.com/en-us/library/ff934521.aspx

        Understanding the Relative Costs of Client Access Server Workloads In Exchange Server 2010

        0
        Filed under Exchange 2010

        Estimating your Exchange Server 2010 Client Access server capacity needs is a critical setup task. The Client Access server is the entry point for all users. In addition, the Client Access server hosts important services used by the other Exchange server roles. This white paper presents an estimate of the relative CPU weights of the different protocols on the Client Access server that can be used to produce a more detailed estimate of hardware needs when you design a new Exchange 2010 deployment or expand an existing one. As part of the testing performed while researching this white paper, the effect of MailTips and the cost of NTML versus Basic authentication were also compared.

        http://technet.microsoft.com/en-us/library/ff803560(EXCHG.141).aspx

        Publishing Exchange 2010 with Forefront UAG 2010 and Forefront TMG 2010

        0
        Filed under Exchange 2010, Forefront TMG and UAG

        Allowing access to corporate resources from any location, perhaps using devices that are not controlled by the organization, presents additional risk to the security of the data and services being accessed. Therefore it’s critical to take measures to ensure that the data is being accessed securely, which means implementing technologies such as certificates, firewalls, enforcing pre-authentication, and device or endpoint validation. This white paper provides detailed information about publishing Microsoft Exchange Server 2010 using Forefront Unified Access Gateway 2010 and Forefront Threat Management Gateway 2010, including how to choose between them for different scenarios, and provides specific steps you can take to configure Forefront TMG and Forefront UAG to publish Exchange 2010.

        This white paper provides information about publishing Microsoft Exchange Server 2010 using Forefront Unified Access Gateway 2010 and Forefront Threat Management Gateway 2010, including how to choose between them for different scenarios, and provides specific steps you can take to configure Forefront TMG and Forefront UAG to publish Exchange 2010.

        Download the whitepaper here

        Exchange Server 2010 Design and Architecture at Microsoft

        0
        Filed under Exchange 2010

        Microsoft IT maintains a complex Exchange environment that consists of several geographic locations and multiple Active Directory forests. There are 16 data centers, four of which host Exchange servers, to support more than 515 office locations in 102 countries with more than 180,000 users.

        By replacing Exchange Server 2007 servers with servers running Exchange Server 2010, Microsoft IT created new opportunities to drive down costs and system complexities while at the same time increasing security and deploying new features not available in previous versions of Exchange Server.

        Download the whitepaper here

        Mount point design and MSSearch

        0
        Filed under Exchange 2007, Exchange 2010

        Source: Tim McMichael

        The use of mount points for Exchange is becoming more common place in many installations.  Some customers feel the best implementation of mount points consists of a small root disk with mount points created from folders on that disk.

         

        For example, I may have a Drive L: that is 10 megs and I may create 4 folders on this drive (Database1 / Database2 / Database3 / Database4).  I will then create mount points utilizing the folders created from the L drive.

        There are certain processes in Exchange that often check for free drive space prior to performing certain operations.  Unfortunately these processes are not necessarily mount point aware – therefore they end up querying the free drive space of the lettered volume rather than the mount point.  One of these processes is MSSearch.

         

        MSSearch by default creates a catalog data folder co-located with each EDB file.  In our example above the catalog data folder and the edb file would be in L:\Database1 (where Database1 is the mount point).  In this this case the L drive has 10 megs free space but the Database1 mount point has 1.5 terabytes of free space.  When MSSearch attempts to initialize the initial catalog this operation fails as the drive space reported by the disk L is not sufficient (even though there is plenty of space where the actual catalog is stored).

         

        Here is an example of some events you may see when this occurs.

        Log Name:      Application
        Source:        MSExchange Search Indexer
        Date:          6/14/2010 12:11:20 PM
        Event ID:      104
        Task Category: General
        Level:         Error
        Keywords:      Classic
        User:          N/A
        Computer:      server.company.com
        Description:
        Exchange Search Indexer failed to enable the Mailbox Database DATABASE(GUID = 58c0ed8a-dbfc-4d55-b265-8a80f1dc477b) after 1 tries. The last failure was: System.ComponentModel.Win32Exception: Unable to SetProperty FTE_PluginList on catalog ExSearch-58c0ed8a-dbfc-4d55-b265-8a80f1dc477b-26fc1c62-d3e8-4711-b3c9-3bb0b32aec0a. Error = -2147215320
           at Microsoft.Exchange.Msfte.CFTEAdmin.SetProperty(CatalogState catalogInfo, PropertyScope propertyScope, String propertyName, Object propertyValue, Boolean throwOnFailure)
           at Microsoft.Exchange.Msfte.CFTEAdmin.CreateCatalog(CatalogState catalogInfo)
           at Microsoft.Exchange.Search.Globals.CreateCatalog(CatalogState state, String reason)
           at Microsoft.Exchange.Search.Globals.RecreateCatalogAndPropertyStore(CatalogState catalogInfo, String reason)
           at Microsoft.Exchange.Search.CatalogState.CreateNew(String reason)
           at Microsoft.Exchange.Search.CatalogState.Reset(String reason)
           at Microsoft.Exchange.Search.CatalogState.HandleMountCatalogException(Exception exception)
           at Microsoft.Exchange.Search.Globals.CheckAndInitializeCatalog(CatalogState catalogInfo)
           at Microsoft.Exchange.Search.Driver.ProcessNewCatalogInternal(CatalogState catalog, List`1 mdbsToCrawl, Int32& numberOfDisabledMDBs). It will retry after 10 minutes.

         

        Log Name:      Application
        Source:        ExchangeStoreDB
        Date:          6/14/2010 12:12:51 PM
        Event ID:      222
        Task Category: Database recovery
        Level:         Error
        Keywords:      Classic
        User:          N/A
        Computer:      server.company.com
        Description:
        At ’6/14/2010 11:12:50 AM’ the Microsoft Exchange Information Store Database ‘DATABASE’ copy on this server experienced a corrupted search catalog. The error returned by failover was “There is only one copy of this mailbox database (DATABASE). Automatic recovery is not available.”. Consult the event log on the server for other “ExchangeStoreDb” and “MSExchange Search Indexer” events for more specific information about the failures.

         

        The important information is actually contained in the first event – the error code –2147215320.  This error code translates to CI_E_CONFIG_DISK_FULL.

         

        To resolve this issue you can:

         

        • Increase the space allotted to the root disk hosting the mount point.
        • Change from utilizing mount points to drive letters.

         

        Once this is done restarting the MSSearch services may be necessary so that initial catalog creation can occur.

        Exchange 2007/2010 Performance Data Collection Script

        0
        Filed under Exchange 2007, Exchange 2010

        Source: Mike lagase

        In efforts to help streamline performance data collection on Exchange 2007/Exchange 2010 servers, I have created a powershell script that will automate the data collection for you. One of the nice features of the script is that you do not have to tell the script what roles are installed as it will automatically detect what is installed locally on the server, thus adding the appropriate counters for you. Previously, you had to manually select an XML file from here for Exchange 2007 servers and here for Exchange 2010 servers and then import it in to the performance console.

        I’ve seen a lot of cases that use the previous Perfwiz utility, but unfortunately, this was originally designed to collect data for Exchange 2003 servers and was never updated to support the later versions of Exchange. This older version of Perfwiz should never be used to troubleshoot performance issues for versions later than Exchange 2003 as the pertinent counters are not being collected to accurately troubleshoot a performance issue.

        During the development phase of this script, it was found that starting with Windows 2003 x64 that the log roll mechanism no longer worked properly and stopped once the maximum log file size was hit. Even though this worked previously in on Windows 2003 x86 versions, something changed on the 64-bit platform which prevented this from working. This problem is also inherent in the Windows 2008 operating system, but eventually was resolved in Windows 2008 R2. The script works around all of these issues to help you collect the right data at the right time by doing the following:

        • If Windows 2003 x64 and –circular switch not specified, then roll log to next log file once maxsize is reached or duration time is hit, whichever one is first.
        • If Windows 2008 RTM/SP1/SP2 and –circular switch not specified, then roll log every 4 hours. If Interval is set to less than 30 seconds, then roll log every hour.

        IMPORTANT: To help save on the disk space consumed to write these log files out, the *default duration* is set to 8 hours. This time duration should be enough to capture most performance cases during the day, but if longer durations are needed, then refer to the switches listed in the table below to help set the desired configuration for your needs.

        Listed below are the switches that can be used with this script at the time of this posting. New switches will be added as time goes on. These switches should help allow you to collect the right data at the right time and also allows the flexibility to set the appropriate settings.

        Parameter

        Description

        -help or -?

        Provides help regarding the overall usage of the script

        -circular

        Turns on circular logging to save on disk space. Negates default duration of 8 hours

        -delete

        Deletes the currently running Perfwiz data collection

        -duration

        Specifies the overall duration of the data collection. If omitted, the default value is (08:00:00) or 8 hours

        -EseExtendedOn

        Enables Extended ESE performance counters

        -EseExtendedOff

        Disables Extended ESE performance counters

        -filepath

        Sets the directory location of where the blg file will be stored

        -full

        Defines a counter set that includes all Counters/instances

        -interval

        Specifies the interval time between data samples. If omitted, the default value is (00:00:30) or 30 seconds

        -maxsize

        Specifies the maximum size of blg file in MB. If omitted, the default value is 512

        -query

        Queries configuration information of previously created Exchange_Perfwiz Data Collector

        -start

        Starts Exchange_Perfwiz data collection

        -stop

        Stops the currently running Perfwiz data collection

        -StoreExtendedOn

        Enables Extended Store performance counters

        -StoreExtendedOff

        Disables Extended Store performance counters

        -threads

        Specifies whether threads will be added to the data collection. If omitted, threads counters will not be added to the collection

        -webhelp

        Launches web help for script

        For additional information, you can check out the website that includes the latest 1.3 version download at http://code.msdn.microsoft.com/ExPerfwiz.

        If you have an issue with this script or have a feature suggestion, use the Discussions/Issue Tracker tabs on the Experfwiz page listed above. There are also additional examples of how to run the script with additional switches on the site.