Latest Entries »


Great querstion from this week’s 10233 design of Exchange 2010 class. Our student asks

“in the past a mailbox move didn’t also move dumpster data. You had to recover it prior to the move. Has this changed in 2010?”

After some digging I was able to confirm that it IS now gathered along with everything else. Confirmed HERE found on the MSexchange.org site. Great article Neil!

 

The move request puts a special system message into the system mailbox on the mailbox database. The Microsoft Exchange Mailbox Replication service checks the contents of the system mailbox on each mailbox database to see if any move requests are waiting and then processes them accordingly. There are many benefits to having the mailbox moves carried out by this service. Here are three main areas that I typically encounter on migration projects that are addressed with move requests:

  • Mailboxes can now be moved online whilst the users are logged into them. Admittedly this is only available if the source mailbox is running Exchange 2007 SP2 or later, or Exchange 2010. However, this is a welcome addition to the overall mailbox moving process as it will help negate the need to move mailboxes out of core business hours.
  • Items in the dumpster are now moved as part of the process. In previous versions of Exchange, moving a mailbox did not move the items in the dumpster and it was therefore required that the user had to recover any deleted items prior to the mailbox move. It was all too easy to forget to inform the users of this fact and in some cases users who had been moved then proceeded to recover items from their dumpster only to find it completely empty.
  • The mailbox contents are no longer processed by the computer running the move process. It was often the case in Exchange 2007 that the Move-Mailbox cmdlet, or associated script, was run on an administrative machine rather than directly on the target Exchange 2007 server. However, in this scenario, the mailbox contents are moved from the source database to the administrative machine and then into the target database. This scenario was mitigated by running the cmdlet or script directly on the target database server. In Exchange 2010 this situation will not be encountered since the mailbox moves are performed by the Microsoft Exchange Mailbox Replication service running on the Client Access Server.
Advertisements

Now the following post has some parts from our friends at Exchangeserverpro.com. Please follow them on Twitter – @Exchservpro. Instead of re-inventing the wheel here I’d post some of their great content from the following two links..

Exchange 2010 CAS backup and recovery

and

Exchange 2010 Hub Transport backup and recovery

 

Now understand these steps listed below are if you are NOT going to be doing bare-metal or full server backups. Those obviously would be the easiest route.

Planning the Client Access Server Backup

As you plan the Client Access server backup strategy there are different techniques that you can consider depending on your requirements.

Backing up Everything

A full system backup of the Exchange 2010 Client Access server, along with a working Active Directory, will have all of the required information to recover the Client Access server.  Naturally this backup takes the longest to run, and will use up the most backup storage.

Backup up the Minimum

To reduce backup storage and keep the backup time frame shorter the minimum data on the Client Access server can be backed up.  This involves backing up the system state of the server, and configuration files stored in the \ClientAccess path of the Exchange Server 2010 installation folder (C:\Program Files\Microsoft\Exchange Server\V14 by default).

Backing up Nothing

It may be practical to not back up the Client Access server at all if:

  • There are multiple, redundant Client Access servers deployed (ie Client Access Server Array)
  • The SSL certificates are exported or retrievable from elsewhere
  • Customizations to the Client Access server virtual directories can be quickly reapplied using an existing script

If all of those conditions are true then the Client Access server may not need to be backed up at all.

Backing Up and Restoring Client Access Servers

In this demonstration a Client Access server has been configured as a single-node NLB cluster and Exchange 2010 CAS array.

Exchange 2010 Client Access server configured with NLB

Exchange 2010 Client Access server configured with NLB

The external URL has also been configured.

[PS] C:\>Get-OwaVirtualDirectory | fl name, *URL*

Name            : owa (Default Web Site)
Url             : {}
Exchange2003Url :
FailbackUrl     :
InternalUrl     : https://ex3.exchangeserverpro.local/owa
ExternalUrl     : https://mail.exchangeserverpro.local/owa
Recovering an Exchange 2010 Client Access Server

Because most of the Client Access server configurtion is stored in Active Directory when a Client Access server has failed you can recover the server using the following procedure.

  1. Install a new server to host the Client Access server role
  2. Configure the server to have the same name, IP address, and domain membership as the server that failed
  3. Install the Exchange Server 2010 pre-requisites
  4. Perform a recovery mode install of Exchange Server 2010

To run Exchange Server 2010 setup in Recovery Mode use the following command from an elevated command prompt.

setup /m:recoverserver

Setup performs a server recovery using the configuration information stored in Active Directory.

Welcome to Microsoft Exchange Server 2010 Unattended Setup

By continuing the installation process, you agree to the license terms of
Microsoft Exchange Server 2010. If you don't accept these license terms,
please cancel the installation. To review these license terms, please go to

http://go.microsoft.com/fwlink/?LinkId=150127&clcid=0x409/

...............
No key presses were detected.  Setup will continue.
Preparing Exchange Setup

    Copying Setup Files              ......................... COMPLETED

The following server roles will be recovered
    Client Access Role
    Management Tools

Performing Microsoft Exchange Server Prerequisite Check

    Client Access Role Checks         ......................... COMPLETED

Configuring Microsoft Exchange Server

    Preparing Setup                  ......................... COMPLETED
    Stopping Services                ......................... COMPLETED
    Copying Exchange Files           ......................... COMPLETED
    Restoring Services               ......................... COMPLETED
    Client Access Server Role         ......................... COMPLETED
    Exchange Management Tools        ......................... COMPLETED
    Finalizing Setup.                ......................... COMPLETED

The Microsoft Exchange Server setup operation completed successfully.
Setup has made changes to operating system settings that require a reboot to tak
e effect. Please reboot this server prior to placing it into production.

After the reboot you can verify that some configurations have been recovered, such as the OWA virtual directory URLs. However any other customized configurations that were stored in the system state or the file system are not recovered by this process. Those settings will need to be reapplied from the minimal backups, or reapplied manually or by using a script.

 

 

 

Planning the Hub Transport Server Backup

When you are planning the Hub Transport server backup strategy there are different approaches you can take depending on your requirements.

Backing up Everything

A full system backup of the server, along with a working Active Directory, encompasses all of the required information for a recovery.  However this backup takes the longest and will consume the most backup storage.

If a server failed and needed to be recovered from a full backup any undelivered messages still in the transport queue would be lost.  But it is impractical to backup the entire server multiple times a day just to protect the transport queue databases from data loss.

Depending on the Exchange environment and the backup infrastructure in place a full server recovery may take longer than simply rebuilding the server from scratch.

Backing up the Minimum

To save on backup storage and minimize the backup time frame the minimum data on the Hub Transport server can be backed up.  For most environments this would mean only backing up the transport queue databases and the log files on the file system.

Because these would be relatively fast to back up this type of backup could be performed multiple times per day to minimize the risk of losing undelivered messages.  This concern would mostly apply to high volume email environments where the transport queues are regularly backlogged.  Of course in those cases some attention should be paid to whatever performance bottleneck is causing the backlog, if it is something within the control of that organization to fix.

Backing up Nothing

A perfectly feasible backup strategy for the Hub Transport server is to back up nothing at all.  This would be practical if:

  • there are multiple, redundant Hub Transport servers deployed
  • the transport queues are not frequently backlogged
  • the organization does not wish to retain any log files from the Hub Transport servers

If all those conditions are true then it may not be necessary to back up the Hub Transport servers at all.

Backing Up and Restoring Hub Transport Servers

For the purposes of this demonstration I’ve configured a Hub Transport server with an additional Receive Connector.

alt

Message tracking logs are also enabled.

alt

Recovering a Hub Transport Server

As mentioned earlier most of the critical Hub Transport server configuration is stored in Active Directory.  When a Hub Transport server has failed you can recover the server using the following process.

  1. Install a new server to host the Hub Transport server role
  2. Configure the server with the same name and IP address as the failed server, and join it to the domain
  3. Install the Exchange Server 2010 pre-requisites
  4. Perform an installation of Exchange Server 2010 using Recovery Mode

To run setup in Recovery Mode use the following command to launch Exchange Server 2010 set from an elevated command prompt.

C:\Admin\Exchange 2010>setup /m:recoverserver

Setup performs a server recovery instead of a normal installation.

Welcome to Microsoft Exchange Server 2010 Unattended Setup

By continuing the installation process, you agree to the license terms of
Microsoft Exchange Server 2010. If you don't accept these license terms,
please cancel the installation. To review these license terms, please go to

http://go.microsoft.com/fwlink/?LinkId=150127&clcid=0x409/

...............
No key presses were detected.  Setup will continue.
Preparing Exchange Setup

    Copying Setup Files              ......................... COMPLETED

The following server roles will be recovered
    Hub Transport Role
    Management Tools

Performing Microsoft Exchange Server Prerequisite Check

    Hub Transport Role Checks        ......................... COMPLETED
 This computer requires the 2007 Office System Converter: Microsoft Filter Pack.
 Please install the software from http://go.microsoft.com/fwlink/?LinkId=123380.

Configuring Microsoft Exchange Server

    Preparing Setup                  ......................... COMPLETED
    Stopping Services                ......................... COMPLETED
    Copying Exchange Files           ......................... COMPLETED
    Restoring Services               ......................... COMPLETED
    Hub Transport Server Role        ......................... COMPLETED
    Exchange Management Tools        ......................... COMPLETED
    Finalizing Setup.                ......................... COMPLETED

The Microsoft Exchange Server setup operation completed successfully.
Setup has made changes to operating system settings that require a reboot to tak
e effect. Please reboot this server prior to placing it into production.

Restart the server as prompted.  When the server has finished restarting you can verify that configurations such as the additional Receive Connector and the message tracking log configuration have been recovered with the server.

alt

alt

However the log files themselves are not restored during a Recovery Mode install of Exchange Server 2010.

alt

Neither are additional applications or agents that were previously installed ont he server.  For the Hub Transport server one notable item would the Microsoft Office Filter Pack.

Therefore the server is not fully recovered until all of those items, along with any further customizations to the server, have been manually applied.


Exchange 2010 allows us a new replication topology when it comes to our mailbox databases, DAG (Database availability groups). You may have noted I didn’t use the general term databases. Public folder databases cannot be used in a DAG. Now to avoid corruption passing to Db copies throughout your organization we now have a capability to use a Lagged copy of the database. which still has all of the transaction logs but just have not applied them.

Walter from this week’s 10135 class was looking for some more information on the entire process of activating a lagged copy and more specifically

“what do I do with the transaction logs if I know where the corruption occurred?”

here ya go buddy – taken from this page – Activate a Lagged Mailbox Database Copy

A lagged mailbox database copy is a mailbox database copy configured with a replay lag time value greater than 0. Activating and recovering a lagged mailbox database copy is a simple process if you want the database to replay all log files and make the database copy current. If you want to replay log files up to a specific point in time, it’s a more difficult operation because you have to manually manipulate log files and run Eseutil.

Dd979786.note(en-us,EXCHG.141).gifNote:

You can’t use the Exchange Management Console (EMC) to activate a lagged mailbox database copy to a specific point in time.

  1. Suspend replication for the lagged copy being activated by using the Suspend-MailboxDatabaseCopy cmdlet, as shown in this example.
  2. Suspend-MailboxDatabaseCopy DB1\EX3 -SuspendComment "Activate lagged copy of DB1 on Server EX3" -Confirm:$false
  3. Optionally (to preserve a lagged copy), take a file system-based (non-Exchange aware) Volume Shadow Copy Service (VSS) snapshot of the volumes containing the database copy and its log files. You can use the vssadmin.exe tool that’s included in Windows to take a VSS snapshot, as shown in this example.
    vssadmin create shadow /For=C:\mountpoints\db01
    vssadmin create shadow /For=C:\mountpoints\db01_logs

    Dd979786.note(en-us,EXCHG.141).gifNote:

    At this point, you have shadow copies outstanding for the database and log volumes. Continuing to perform this procedure on the existing volume would incur a copy on write performance penalty. If this isn’t desirable, you can copy the database and log files to another volume to perform the recovery.

  4. Determine which log files are required to replay into the database to meet your point-in-time requirement for this recovery (based on log file date and time, as shown in Windows Explorer). All logs created after this point should be moved to a different directory, until the recovery process is completed, and the logs are no longer needed.
  5. Delete the checkpoint (.chk) file for the database.
  6. Use Eseutil to perform the recovery operation, as shown in this example.
    Eseutil.exe /r eXX /a

    Dd979786.note(en-us,EXCHG.141).gifNote:

    In the preceding example, eXX is the log generation prefix for the database (for example, E00, E01, E02, and so on).

    Dd979786.important(en-us,EXCHG.141).gifImportant:

    This step may take a considerable amount of time, depending on several factors, such as the length of the replay lag time, the number of log files generated during that period, and the speed at which your hardware can replay those logs into the database being recovered.

  7. After log replay is finished, the database is in a clean shutdown state and can be copied and used for recovery purposes.
  8. After the recovery process is complete, resume replication for the database that was used as part of the recovery process, as shown in this example.
    Resume-MailboxDatabaseCopy DB1\EX3

That VP has been hounding you for his new laptop. You know he’s moving from Outlook 2003 or 2007. PST files are easy to locate and move. How about “Autocomplete” or “Type ahead” data when entering in the To: and other addressing fields?

This is usually where some support people forget to go the extra mile and make a transition like this a seamless process to the end-user. It’ IS a customer. Just an Internal customer. Why skimp now. Do it right, do it well, look like an IT superstar. When I was in my support days the best compliment a user could give me was…

“Oh, that’s it? I just use it like I did before? That was easier than I thought.”

Everyone’s favorite Exchange MVP Jeff Guillet from sunny California aids us in the step with a “Solarz approved and fully awesome” blog post on Transferring Auto-Completion information to Outlook 2010

Here is just a teaser – hit his blog for all the info!

All versions of Outlook since Outlook 2003 have had a feature called Auto-Complete.  Auto-Completion "remembers" recipient names and email addresses that you have used before and offers to complete the email address as you type characters.  This works within Outlook and OWA 2010.

In Outlook 2003-2007, the Auto-Completion (aka NickName) data is stored in a hidden N2K file.  This file is located in the following path:

Make sure you follow him on twitter for his fun musing and great Exchange info! @Expta


Our friends over at Exchange server pro (http://exchangeserverpro.com/) had an AWESOME write up on using Exchange’s new Database Availibility Groups on top of VMWare virtualization. Worth a read for sure! Heck – just look at this part alond..

Microsoft clearly states that hypervisor HA features should be disabled for DAG members, while VMware considers it to be an effective solution.

Microsoft vs VMware on Exchange Virtualization and HA Best Practices

Also if you’re a twitter head like myself make sure you follow them!

@ExchServPro


One of my students from this week’s 10135 class asked a great question…

Where can I see which services are used for each of the roles?

Great question! I stumbled upon a technet article that maps out just that!

Overview of Services Installed by Exchange Setup

 

Now for clarity sake I’ve taken the content from TechNet’s page above and dropped it into an .XLSX file for your convenience here..

Exchange 2010 Service List

Lync is all grown up


,,

Well it appears that Lync 2010 (A.K.A. – new OCS product) has finally hit the RTM phase of it’s life cycle. I can’t wait to download the final bits and test it in a lab environment along side a Exchange 2010 server with Office 2010 clients!

What IS Lync anyway? The home Lync site describes it as..

  "Microsoft Lync Server 2010 delivers complete presence, instant
messaging, conferencing and enterprise voice capabilities through a
single, easy-to-use interface that is consistent across PC, browser, and
mobile device. Administrators benefit from a single, consistent
management infrastructure, new capabilities to increase availability,
and interoperability with existing systems"

The announcement and the prodcut is also descibed on the Microsoft Unified Communications team blog

Sound interested? enterprise VOIP / IM and more? Don’t want to pay for the infrasturcture to support it? Have you checked out the Office365 suite yet?

 



Microsoft has now published a list of OSDX connector files for some of the more popular sites they host and a few others. What is an OSDX file and why do I care? See my preivous post on OSDX connectors for Windows 7

 

good list for sites like..

Bing news

Bing Images

Bing local

YouTube

Yahoo

Yahoo News

Yahoo Images

VL Program guides

Wikipedia

Google blogs

Google News

Flikr

TechNet

MSDN

 

It’s all about being able to search more than just your local pc, all without even having to open up a browser! Our friends over at Bink put up a nice consolodated list of the connectors with links to each’s download page – Enjoy

 

Bink.Nu – MSFT releases search connectors


“so I have 3,000 mailboxes in a single, multi domain forest. When I go to recipient configuration I only see a subset of them all? What gives Chad?”

Great question!

By design the exchange management console only shows recipients from the currently connected to domain. To change this you need to change the scope of the filter. This allows you to change and see the entire forest contents or just another domain.

Don’t forget though there is a default limit to the number of items displayed for that filter set. Out of the box this is 1,000 objects. This too is customizable but it may affect performance.


Bob had a great question when it came to published CRL’s vs Online responders.

“Why is one preferred, and when is one used over the other?”

To get to the bottom of this let’s see how the validation process works. SEE Certificate Revocation and Status Checking

Certificate Status Checking

When an application requests the certificate chaining engine to evaluate a certificate, the validation is performed on all certificates in that certificate’s chain. This includes every certificate from the leaf certificate presented to the application to the root certificate.

When the first certificate in the chain is validated, the following process takes place.

  1. The chaining engine will attempt to find the certificate of the CA that issued the certificate being examined. The chaining engine will inspect the local system certificate stores to find the parent CA certificate. The local system stores include the CA store, the Root store, and the Enterprise Trust store. If the parent CA certificate is not found in the local system certificate stores, the parent CA certificate is downloaded from one of the URLs available in the inspected certificates AIA extensions. The paths are built without signature validation at this time because the parent CA certificate is required to verify the signature on a certificate issued by the parent CA.

  2. For all chains that end in a trusted root, all certificates in the chain are validated. This involves the following steps.

    • Verify that each certificate’s signature is valid.

    • Verify that the current date and time fall within each certificate’s validity period.

    • Verify that each certificate is not corrupt or malformed.

  3. Each certificate in the certificate chain is checked for revocation status. The local cache is checked to see if a time valid version of the issuing CA’s base CRL is available in the cache. If the base CRL is not available in the local cache, or the version in the local cache has expired, the base CRL is downloaded from the URLs available in the CDP extension of the evaluated certificate. If available, it is confirmed that the certificate’s serial number is not included in the CA’s base CRL.

    When a root certificate—a certificate that contains the same DN for both the Subject and Issuer attributes—is encountered, a revocation check may or may not occur. If the certificate chaining engine behavior will depend on whether the application enables the CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT flag, which is the default, the root CA’s certificate is not checked for revocation. If the flag is not enabled, the root CA certificate is checked for revocation if the root CA certificate includes the CDP extension. If the CDP extension is not included, no revocation check is performed.

    Note  Windows XP RTM and Windows XP SP1 will perform revocation checking as the chain is built, rather than only performing revocation checking on chains that end at a trusted root CA.

  4. If the base CRL contains the Freshest CRL extension, the local cache is checked to see if a time valid version of the issuing CA’s delta CRL is available in the cache. If available, it is confirmed that the certificate’s serial number is not included in the CA’s delta CRL. If the delta CRL is not available in the local cache, or the version in the local cache has expired, the delta CRL is downloaded from the URLs available in the CDP extension of the evaluated certificate.

    Warning  If delta CRLs are enabled at a CA, both the base CRL and delta CRL must be inspected to determine the certificate’s revocation status. If one of the two, or both, are unavailable, the chaining engine will report that revocation status cannot be determined, and an application may reject the certificate.

Once the validation check is completed, the certificate chaining engine returns the results of the validation check to the calling application. The results will indicate if all certificates in the chain are valid, if the chain terminates at a non-trusted root CA, if any certificates in the chain are not valid, or if the revocation status for any of the certificates in the chain cannot be determined.

Note  If any certificate in the chain cannot be validated or is found to be revoked, the entire chain takes on the status of that one certificate.

 

Ok, now that we’ve got the validation part down. Let’s take a peek at Online Responders. What do they do differently than the CA and published CRL’s?

An Online Responder is a trusted server that receives and responds to individual client requests for information about the status of a certificate.

The use of Online Responders is one of two common methods for conveying information about the validity of certificates. Unlike certificate revocation lists (CRLs), which are distributed periodically and contain information about all certificates that have been revoked or suspended, an Online Responder receives and responds only to individual requests from clients for information about the status of a certificate. The amount of data retrieved per request remains constant no matter how many revoked certificates there might be.

In many circumstances, Online Responders can process certificate status requests more efficiently than by using CRLs. For example:

  • Clients who connect to the network remotely and either do not need nor have the high-speed connections required to download large CRLs.
  • A network needs to handle large peaks in revocation checking activity, such as when large numbers of users log on or send signed e-mail simultaneously.
  • An organization needs an efficient means to distribute revocation data for certificates issued from a non-Microsoft certification authority (CA).
  • An organization wants to provide only the revocation checking data needed to verify individual certificate status requests, rather than make available information about all revoked or suspended certificates.

Now the application has to be configured to use an Online responder. it’s not going to just figure it out on it’s own.