How to move data using PowerShell when migrate to Exchange 2010

You’ve made the decision to migrate to Exchange Server 2010. After you’ve brought Exchange Server 2010 into your existing Exchange organization and properly prepared Active Directory, the next step is to move mailboxes, public folders and PST data from your old Exchange servers to your new Exchange 2010 servers. You’ll need PowerShell to accomplish these tasks.

Note: You can move content between mailbox servers using the graphical user interface, but it’s usually easier to use Exchange Management Shell commands because you can perform bulk moves using a single line of code.

Moving mailboxes to Exchange 2010 using PowerShell
In Exchange Server 2010, mailbox moves are performed using move requests. A move request requires the name of the mailbox being moved as well as the name of the target database. If you don’t specify a target database, Exchange will select one at random.

For example, if you wanted to move a mailbox named User1 to an Exchange 2010 database named DB1, you could use the following command:

New-MoveRequest –Identity User1 –TargetDatabase DB1

Now that you know how to move a single mailbox, a more efficient approach is to move allof the mailboxes from an entire mailbox database with a single command. For example, to move all of the mailboxes from DB1 to DB2, use the following command:

Get-Mailbox –Database DB1 | New-MoveRequest –TargetDatabase DB2

It’s also possible to create a detailed report of the moves after they’ve been completed. The report can be written to a text file or to a CSV file. To create a move report and write the output to a file named C:MOVE.LOG, enter the following command:

Get-MoveRequest | Get-MoveRequestStatistics | Select DisplayName, Status, TotalItemSize, TotalMailboxItemCount, BytesTransferred, ItemsTransferred | Out-File –FilePath “C:move.log”

If you don’t want to wait to check the status of the move, you can also generate a report to find out how it is progressing. If you want to see how far along the move is, use the following command:

Get-MoveRequest | Get-MoveRequestStatistics | Select DisplayName, Status, PercentComplete, BytesTransferred, ItemsTransferred | Out-File –FilePath “C:move.log”

When all your mailbox moves complete, you must terminate the move request. If you don’t, you won’t be able to move the mailboxes again should the need arise. To terminate a move request, use the Get-MoveRequest | Remove-MoveRequest command.

Moving public folders to Exchange 2010 using PowerShell
Public folders are not a requirement in Exchange Server 2010 unless you plan on having an Exchange 2010 mailbox server that supports clients running Outlook 2003 or earlier. That said, if you have public folders on your legacy Exchange servers that contain useful data, you can move them to Exchange 2010 using PowerShell.

To move all of the public folder replicas from one Exchange server to the other, open the Exchange Management Shell, and enter the following commands:

Set-ExecutionPolicy Unrestricted
CD
CD “Program FilesMicrosoftExchange ServerV14Scripts”
./MoveAllReplicas.ps1 –Server <old server name> -NewServer <new server name>

When the process completes, set the execution policy back to RemoteSigned by entering theSet-ExecutionPolicy RemoteSigned command.

Importing PST files into Exchange 2010 using PowerShell
Exchange Server 2010 is the first version of Exchange to support personal archive mailboxes. Many organizations place archive mailboxes onto dedicated mailbox servers that are equipped with low-cost storage, so that user archives do not affect the performance of the primary user mailboxes.

Archive mailboxes offer a great alternative to PST files, and many organizations have begun moving PST file contents to archive mailboxes as a part of the migration process. Note, however, that this method works only for Exchange 2010 SP1. The RTM release of Exchange 2010 used a different PowerShell cmdlet that was buggy. You should also know that this cmdlet doesn’t create the archive mailboxes; so make sure that the archive mailboxes actually exist before using it.

To import a PST file into an archive mailbox, use the New-MailboxImportRequest –FilePath <the path to the PST file> -Mailbox <mailbox name> -IsArchive cmdlet.

ActiveSync management from the command line in Exchange 2010 SP1

Microsoft’s recent disclosure that PowerShell will play a larger role in server management gives Exchange administrators another reason to familiarize themselves with the command line. Consider the growing number of mobile and remote users and you’ll see why it helps to master the commands necessary to manage ActiveSync.

The Exchange Management Shell commands discussed here are intended for use with Exchange 2010 SP1. Many of these commands exist in earlier versions of Exchange, but in certain cases, Microsoft has changed the syntax.

Creating a new ActiveSync mailbox policy via the Exchange Management Shell
Creating new ActiveSync mailbox policies from the command line may seem pointless to some. After all, many administrators create a single ActiveSync mailbox policy and it’s all they need. However, it’s important to realize there are many different mobiles devices out there and they all have different capabilities.

You can achieve a more granular level of control if you create a separate ActiveSync mailbox policy for each device type, and then base each policy around an individual device’s capabilities. For example, you can create one policy for Windows phones and a separate policy for iPhones.

To create a new ActiveSync mailbox policy, use the New-ActiveSyncMailboxPolicy command and append the –Name parameter. You must also assign the new policy a descriptive name. Your command will look similar to this:

New-ActiveSyncMailboxPolicy –Name ‘<policy name>’

After you create an ActiveSync mailbox policy, you must assign policy values. There are a number of parameters you can append to this command depending on how you’d like to configure the policy. Here are some commonly used parameters:

AllowNonProvisionableDevices
DevicePasswordEnabled
AlphanumericDevicePasswordRequired
MaxInactivityTimeDeviceLock
PasswordRecoveryEnabled
RequireDeviceEncryption
AttachmentsEnabled
AllowSimpleDevicePassword

Assign either a $True or $False value to all of these parameters. Other parameters require numerical values, while the Unlimited and $Null values can take the place of numbers. Here are some examples:

MinDevicePasswordLength $Null
DevicePasswordExpiration ‘Unlimited’
DevicePasswordHistory ‘0’

Below, observe that I’ve created an ActiveSync mailbox policy with all the aforementioned parameters:

New-ActiveSyncMailboxPolicy –Name ‘<policy name>’ -AllowNonProvisionableDevices $False –DevicePasswordEnabled $False –AlphanumericDevicePasswordRequired $False –MaxInactivityTimeDeviceLock $False –PasswordRecoveryEnabled $False –RequireDeviceEncryption $True –AttachmentsEnabled $True –AllowSimpleDevicePassword $True -MinDevicePasswordLength $Null -DevicePasswordExpiration ‘unlimited’ -DevicePasswordHistory ‘0’

Adding a user to an ActiveSync mailbox policy via the Exchange Management Shell
Just as you can create an ActiveSync mailbox policy from the command line, you can also add users to the policy via an Exchange Management Shell (EMS) command:

Set-CASMailbox <user name> -ActiveSyncMailboxPolicy(Get-ActiveSyncMailboxPolicy “<policy name>”).Identity

For example, if you want to add a user named JaneD to an ActiveSync mailbox policy namedWindowsPhone, you can use the following command:

Set-CASMailbox JaneD –ActiveSyncMailboxPolicy (Get-ActiveSyncMailboxPolicy “WindowsPhone”).Identity

Retrieve mobile device usage statistics via the Exchange Management Shell
You can use the Get-ActiveSyncDeviceStatistics command in two ways. For one, you can use it to retrieve ActiveSync usage statistics for an individual user. To do so, use the following command:

Get-ActiveSyncDeviceStatistics –Identity <user name>

You can also use this command to create a report detailing the end users in your organization that have devices linked to their Exchange mailboxes. You can then display usage statistics for those devices. This command’s syntax is tricky because you must apply a filter to prevent client access server-related statistics from displaying alongside the mobile device usage statistics. To do so, use the following command:

Get-CASMailbox –Filter {HasActiveSyncDevicePartnership –eq $true and –not DisplayName –Like “CAS_(*”} | Get-Mailbox | ForEach { Get-ActiveSyncDeviceStatistics –Mailbox $_}

View which mobile devices are in use via the Exchange Management Shell
To find out how many devices a user has, use the Get-ActiveSyncDevice command. The reasons to use this command are similar to those of the Get-ActiveSyncDeviceStatisticscommand. For example, to view the devices registered to an individual user, use the following command:

Get-ActiveSyncDevice –Identity <user name>

To view all devices for all users in your Exchange organization, use the following command:

Get-CASMailbox –Filter {HasActiveSyncDevicePartnership –eq $true and –not DisplayName –Like “CAS_(*”} | Get-Mailbox | ForEach { Get-ActiveSyncDevice –Mailbox $_}

Run Exchange 2010 backup or skip this

When Exchange Server 2010 RTM hit, some IT pros suggested that database availability groups in Exchange 2010 make traditional backups unnecessary.

I initially scoffed at the idea. However, Exchange 2010 has been available for a while and the idea of a “backup-less” Exchange server makes sense in some environments.

The concept behind ‘backup-less’ Exchange
A backup is nothing more than a point-in-time copy of your data. It is this deceptively simple definition that led to the idea of running Exchange 2010 without backups.

Some say running Exchange 2010 without backups is safe because of the way database availability groups (DAGs) work. A single DAG can contain up to 16 mailbox servers and an individual mailbox database can be replicated to any combination of mailbox servers within the DAG.

The argument against backing up Exchange 2010 boils down to how many copies of data you really need. If you already have 16 replicas of a mailbox database, do you really need a seventeenth copy as backup?

Important Exchange backup considerations
While the argument against backing up Exchange 2010 in environments with DAGs sounds logical, there are a number of important factors to consider before ditching your backup system.

• DAG size
  While you can include up to 16 mailbox servers in a DAG, you can also create very small groups. Therefore, you must consider the size of your DAG before abandoning backups. Microsoft recommends that you only consider going without a backup if you have three or more mailbox servers in your DAG.

• Transaction logs
  Typically, when you back up an Exchange mailbox server, the contents of transaction logs are committed to the database as part of the backup process. If you never perform a backup, the transaction logs accumulate until the volume runs out of disk space. Because of this, organizations that do not back up Exchange 2010 must enable circular logging to prevent log file accumulation.

• Offsite storage
  It’s easy to think of a backup-less Exchange organization in the same way as a disk-based backup solution because database contents are replicated to other servers.However, organizations that depend on disk-based backups usually adopt a disk-to-disk-to-tape solution where the disk-based backups are periodically copied to tape and stored offsite. If the data center burns down, the backups remain safe.

  If you’re considering operating Exchange without backups, it’s smart to place a few DAG members in a remote data center. That way, your data remains protected even if something happens to your primary data center.

• Point-in-time recovery
  The biggest disadvantage to running Exchange 2010 without backups is that you lose the option of accurate point-in-time recoveries. For example, imagine that your entire company became infected with a virus.In this situation, you could restore a backup that was made prior to the infection, rather than trying to remove every infected message from your mailbox database. This is simple with a traditional backup, but isn’t practical if you go without.

  Notice that I didn’t say that it’s impossible to perform a point-in-time recovery without a backup. Microsoft does let you create lagged database copies that log files are not immediately replayed on. That way, if you need to revert to a particular point in time, you can activate a lagged copy.

  The problem is that there’s a lot of guess work involved in the process. You must know exactly when the problem began in order to get rid of all of the transaction logs that were created after the problem occurred. This is accomplished by replaying the transaction logs that were created prior to the problem. Unfortunately, there isn’t an easy way to figure out which transaction logs should be used and which should be deleted.

  As you can see, it’s perfectly feasible to run Exchange 2010 without traditional backups in certain situations. That said, I advise backing up Exchange as you always have. If an unforeseen set of circumstances leads to data loss, you won’t have to explain to your boss or management that you don’t have backups.

Cleanup the Exchange 2003 from Active Directory to install Exchange 2010

When installing Exchange 2010, one area that you can overlook is the state of Active Directory. When you install Exchange 2010, Setup assumes that the Active Directory database is in pristine condition. However, organizations that have been using Exchange for many years often have Exchange 2003 remnants in AD. These remnants can halt an Exchange 2010 installation. The method described in this article should remove the server in question from Active Directory to the point where you’re able to install Exchange 2010.

Warning! Any mistakes made during implementation can damage Exchange servers or you’re the Active Directory forest. Back up domain controllers before attempting any of these techniques.

These procedures are only intended for situations in which a server no longer exists in your organization, but some fragments have been left behind in AD. If the server still exists in your Exchange organization, you should remove it.

To remove any lingering portions of an old Exchange 2003 server from Active Directory, use the Windows Support Tool ADSI Edit.

The Windows Support Tools are included with Windows Server, but are not installed by default. The exact method to install these tools varies depending on the version of Windows you’re using. If you’re having trouble locating it, look for an installer in the SupportTools folder on the Windows installation DVD.

Next, open ADSI Edit, which is located in the Program FilesSupport Tools folder, and connect it to a domain controller, if necessary. Then navigate through the console tree to:

Configuration
CN=Configuration, DC=<your domain>, DC=com
CN=Services
CN=Microsoft Exchange
CN=<your organization name>
CN=Administrative Groups
CN=<Your Administrative Group Name> Note: This could also be an Exchange 5.5 site name
CN=Servers

These container names may not exactly match those in your organization. For example, the first node of the hierarchy that I’ve listed is Configuration. Although this is technically the node’s name, ADSI Edit also displays the name of your domain controller in brackets. For example, on my server this container is listed as Configuration [tazmania.production.com]

Selecting the CN=Servers container lists Exchange servers within the administrative group that you’ve selected. If you need to eliminate references to a specific server, right-click on the server object (not the CN=Servers container) and select Delete. A confirmation will ask if you want to delete that server. Verify that you’ve selected the correct server and click Yes.

 

In some situations, there may be a few stray objects, such as routing group connectors, that must be manually removed. Use Exchange management tools to manually remove these objects.

 

How to become a command line savvy in Exchange 2010

An Exchange admin with PowerShell skills is a valuable asset, especially as organizations move to Exchange Server 2010. Exchange Management Shell enables admins to manage every aspect of Exchange 2010. Even if you don’t consider yourself command-line person savvy, don’t be intimidated. Now is the time to become familiar with Exchange Management Shell and PowerShell cmdlets.

EMS is built on top of Windows PowerShell 2.0. EMS and Windows PowerShell focus on managing objects in large groups, an act that traditionally had been difficult with GUI-based tools. When you have thousands of objects, it can be difficult to find the three that you have to modify. Having a tool that can consistently find and edit those objects with minimal typing and interpretation is invaluable.

Cmdlet basics
So, what is a cmdlet? At its simplest, a cmdlet is a combination of a verb and a noun. The verb might be an action like Get that will retrieve information about an object or objects. The noun is the object that the action is performed on, like a mailbox. Put the two together and you have:

Get-Mailbox

Launch Exchange Management Shell in Exchange 2010 and type the cmdlet. In the output, EMS will list all the mailboxes in your organization. If you want to retrieve a list of sales mailboxes in your Exchange organization, you would use a command similar to:

Get-Mailbox -OrganizationalUnit Sales

Now, suppose you wanted to retrieve information for all mailboxes on a server calledTampaMBX02. In that case, you would use a command similar to:

Get-Mailbox -Server TampaMBX02

Piping cmdlets together
Now that you understand the basics, let’s go a little deeper. Suppose you

want to prevent these sales mailboxes from sending and receiving mail after they reach 500 MB. To do so, you could set a 500 MB Prohibit Send quota on them. After you’ve collected the mailboxes you need, you just need to set the quota. To take the result set from one cmdlet and pass it to another cmdlet, you must use the pipe symbol (|). To accomplish this, simply put the two parts together as such:

Get-Mailbox -OrganizationalUnit Sales | Set-Mailbox -ProhibitSend 500MB -UseDatabaseQuotaDefaults $false

In this example, I appended the -UseDatabaseQuotaDefaults $false parameter. This ensures that database settings won’t be applied and won’t overwrite the recipient settings you’re trying to configure.

As another example, suppose you wanted to give your executives unlimited mailbox quotas, but your execs are spread across multiple mailbox databases and multiple servers. You’d have to use the ProhibitSend quota and append it with a cmdlet for the distribution list associated with those executives:

Get-DistributionGroup Executives | Get-DistributionGroupMembership | Set-Mailbox -ProhibitSend Unlimited -UseDatabaseQuotaDefaults $false

In just a few moments, you’ve gone from a simple Get-Mailbox cmdlet to a fairly sophisticated one.

The WhatIf parameter
If you’re still nervous that your scripting inexperience might harm Exchange, don’t worry. The WhatIf parameter lets you observe potential changes to objects before making them. If you’re satisfied with the results, you can use the same cmdlet in the PowerShell prompt, delete the WhatIf parameter and re-execute the cmdlet. For example, to move all mailboxes on a server to a database on a new server, use the New-MoveRequest cmdlet with the WhatIf parameter to check the mailboxes’ readiness before executing the move. The command looks like this:

Get-Mailbox -Server SearchExchangeEX1 | New-MoveRequest -TargetDatabase “SearchExchangeDB2” –WhatIf

The command simulates what would happen if you moved all mailboxes off theSearchExchange-EX1 server to the SearchExchangeDB2 database without actually making the move. If the mailboxes aren’t ready to be moved, you’ll receive an error message. If there are no errors, execute the command again without the WhatIf parameter:

Get-Mailbox -Server SearchExchangeEX1 | New-MoveRequest -TargetDatabase “SearchExchangeDB2”

Tab completion for cmdlets
One very useful PowerShell shortcut once you’ve learned started writing commands is Tab completion, or Tab expansion, which lets you complete portions of cmdlets using the Tabkey. Type the verb and a few characters of the noun and press Tab. For example, you could begin typing Get-M and press the Tab key until Get-Mailbox appears. If you accidentally tab past Get-Mailbox, just hold down the Shift key and press Tab repeatedly to move backward through the list of cmdlets until you reach the one you want.

Even though case is not important in PowerShell, tab completion also automatically corrects case. Type get-dist and press the Tab key. In my opinion, Get-DistributionGroupMembership reads much cleaner than get-distributiongroupmembership, though it is only a cosmetic change and they both accomplish the same thing.

 

 

Best practices for virtualizing Exchange 2010 server roles

When virtualizing Exchange Server 2010, it’s important to correctly configure virtual machines (VMs) that will host certain Exchange Server roles – otherwise a few gotchas will surface. For example, you’ll need to assign the correct number of processors to the appropriate amount of RAM. This tip gives more advice for correctly configuring VMs for optimal performance.

Client access and hub transport servers

Even in small Exchange environments, the Client Access Server role and the Hub Transport Server role are commonly collocated with the Mailbox Server role on a single computer. For organizations with hundreds or thousands of mailboxes, this is an all-in-one configuration.

Resource requirements for the CAS are usually less than what the hub transport server traditionally needs. Since every piece of mail in an Exchange Server 2010 organization flows through the hub transport server — for routing and messaging policy application purposes — it bears a heavy load.

Microsoft states that each role should be given a minimum of 2 GB of RAM, with a recommended setting of 1 GB per core for the hub transport server and 2 GB per core for the client access server. Comparative requirements for the client access server can be larger in environments that heavily rely on Outlook Web App (OWA).

As a rule, virtualization environments work best when VMs are configured with the smallest number of processors possible. The processor power requirements of your Exchange 2010 environment will determine that number. Starting small and working up is the best rule of thumb.

Microsoft suggests eight cores for the hub transport server and four cores for the client access server to support an organization of several mailbox servers and thousands of mailboxes. Organizations with fewer mailboxes and lower levels of non-MAPI client traffic could start with as few as two cores.

Edge transport servers

Edge transport servers typically consume lower levels of resource utilization. This level can depend on the rate of inbound and outbound mail flowing through your Exchange organization, along with your level of rejected mail. If your organization deploys spam filtering from an upstream provider, this reduction in traffic can affect edge transport resource utilization.

Microsoft also suggests configuring edge transport servers with a single processor core and up to a maximum of twelve cores — if your virtual platform will support them. RAM requirements start with a minimum of 2 GB with 1 GB per core. You can always add more memory later if you experience excessive paging, poor performance or an email build-up in messaging queues.

Unified messaging servers

This is easy — don’t virtualize unified messaging servers. Microsoft does not support them. Unified messaging servers require substantial processing power and have little tolerance for processing latency. Microsoft’s suggestion for even a small Exchange organization is a minimum of two to four cores and 4 GB of RAM, with 2 GB per core of RAM. If you’re using unified messaging, I advise that you steer clear of virtualization for now.

Mailbox servers

Mailbox servers are the heavy-lifters in any Exchange infrastructure; they are where resources are used in larger quantities. You might want to consider virtualizing mailbox servers last. While they can be virtualized, they require careful evaluation before beginning. Experience gained from virtualizing Exchange’s other less-challenging roles will help.

Microsoft states that a four-core mailbox server should be able to support several thousands of mailboxes. The RAM recommendation for that server starts with 4 GB of RAM plus an additional 3 to 30 MB per mailbox. Virtualizing any mailbox server will consume a large share of your virtual host’s available RAM resources, so plan accordingly and don’t oversubscribe your virtual infrastructure.

Exchange Server 2010 virtualization gotchas

Exchange Server organization’s mail usage characteristics have more to do with these calculations than any RAM or core numbers suggested here. Measuring your existing metrics on physical servers is the first step in preparing to virtualize Exchange Server. Measured over time, those metrics are necessary to determine your starting points for processor and memory resource assignment.

Microsoft states that relying on someone else’s numbers is a flawed assumption. In Understanding Server Role Rations and Exchange Performance, Microsoft notes, “A significant percentage of the server processing is associated with the overhead of analyzing connections and scanning accepted messages. For this reason, it’s not possible to provide a sizing metric based solely on the number of messages sent and received per second….”

While this quote relates specifically to the activities within the edge transport server, it’s also good advice for the other roles. If you don’t correctly determine a baseline for your Exchange 2010 server role performance before you begin a virtualization project, any or all of the roles may cause trouble.

Configuring EdgeSync in Edge Transport Server – Exchange 2010

In the last part of this series I demonstrated how to install the Edge Transport server role for Exchange Server 2010. In this next part I’ll go through the process of configuring the Edge Subscription between the Edge Transport server and Hub Transport server located in the internal network.

The Edge Subscription is a relationship between an Edge Transport server and an Active Directory site, and allows the Edge Transport server to receive information about the Exchange organization such as recipients, domain names, and safelists/blocklists for anti-spam.

This information is synchronized at regular intervals through a process called EdgeSync.

Firewall Ports for Exchange Server 2010 Edge Transport Servers

For EdgeSync and mail flow to work there are a few network ports that need to be open on the firewall between the Internet, the Edge Transport server, and the internal Hub Transport server.

Edge Transport Server Network Ports for EdgeSync

• Secure LDAP (TCP 50636) from the Hub Transport server to the Edge Transport server
  

Edge Transport Server Network Ports for Mail Flow

• SMTP (TCP 25) from the Internet to the Edge Transport server
  
• SMTP (TCP 25) from the Edge Transport server to the Hub Transport server
  
• SMTP (TCP 25) from the Hub Transport server to the Edge Transport server
  
• DNS (UDP 53) from the Edge Transport server to a DNS server capable of public DNS lookups (ie to look up MX records)
  

  
  

Configuring ISA Server 2006 for Edge Transport Servers

If you are using ISA Server 2006 as your firewall and want to create the access rules for the Edge Transport server the first thing you’ll need to configure is a new network protocol for the secure LDAP connection. ISA Server 2006 is pre-configured with a secure LDAP protocol however the EdgeSync process uses the non-standard port of TCP 50636.

Create a new network protocol named “EdgeSync” for TCP 50636 outbound.

Configure the ISA Server 2006 firewall policy with access rules for the Edge Transport network access required.

Creating the Edge Subscription for Exchange Server 2010 Edge Transport Servers

With the firewall access all configured correctly the next step is to configure the Edge Subscription itself.

On the Edge Transport server open the Exchange Management Shell and run the following command using the New-EdgeSubscription cmdlet.

[PS] C:>New-EdgeSubscription -FileName C:edgesubscription.xml

 

Confirm

If you create an Edge Subscription, this Edge Transport server will be managed via EdgeSync replication. As a result,

any of the following objects that were created manually will be deleted: accepted domains, message classifications,

remote domains, and Send connectors. After creating the Edge Subscription, you must manage these objects from inside

the organization and allow EdgeSync to update the Edge Transport server. Also, the InternalSMTPServers list of the

TransportConfig object will be overwritten during the synchronization process.

EdgeSync requires that this Edge Transport server is able to resolve the FQDN of the Hub Transport servers in the

Active Directory site to which the Edge Transport server is being subscribed, and those Hub Transport servers be able

to resolve the FQDN of this Edge Transport server. You should complete the Edge Subscription inside the organization in

the next “1440” minutes before the bootstrap account expires.

[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is “Y”): y

There are two important things to be aware of here:

• You must complete the next step of the Edge Subscription process within 1440 minutes (24 hours), otherwise you’ll need to generate a new Edge Subscription again
  
• The Hub Transport servers in the Active Directory site that will be subscribed must be able to resolve the FQDN of the Edge Transport server. You can either add DNS records manually or use a HOSTS file entry.
  

Copy the “edgesubscription.xml” file to the Hub Transport server. Launch the Exchange Management Console and navigate to Organization Management/Hub Transport.

In the Actions pane click on New Edge Subscription.

 

Browse and select the Active Directory site to be subscribed, as well as the XML file that you copied from the Edge Transport server.

Click the New button to complete the wizard.

After the Edge Subscription has been created you will see two Send Connectors configured for your organization.

 

It can take up to an hour before the first Edge synchronization process runs, but you can run it manually if you need to. On the Hub Transport server launch the Exchange Management Shell and run the following command using the Start-EdgeSynchronization cmdlet.

[PS] C:>Start-EdgeSynchronization -Server esp-ho-ex2010a

 

RunspaceId : b7415ae2-f763-449e-bb36-20a6a18759cd

Result : Success

Type : Configuration

Name : Exchnage-Test

FailureDetails :

StartUTC : 5/7/2011 1:27:39 PM

EndUTC : 5/7/2011 1:28:07 PM

Added : 290

Deleted : 0

Updated : 0

Scanned : 295

TargetScanned : 0

 

RunspaceId : b7415ae2-f763-449e-bb36-20a6a18759cd

Result : Success

Type : Recipients

Name : Exchange-test1

FailureDetails :

StartUTC : 5/7/2011 1:27:39 PM

EndUTC : 5/7/2011 1:28:08 PM

Added : 401

Deleted : 0

Updated : 0

Scanned : 401

TargetScanned : 0

After the initial Edge synchronization has occurred you will be able to see the Send Connectors and Accepted Domains configured on the Edge Transport server.

Testing Mail Flow

After the Edge Subscription is in place and you’ve synchronized at least once you can send email between your Exchange organization and an external mailbox, and then inspect the email message headers to verify that the messages are traversing your Edge Transport server.

Received: from Exchange-test (10.0.3.2) by

Exchange-test1 (10.0.1.4) with Microsoft SMTP Server

(TLS) id 14.1.289.1; Sat, 7 May 2011 23:50:10 +1000

Received: from (192.168.0.45) by Exchange-test

(10.0.3.2) with Microsoft SMTP Server id 14.1.218.12; Sat, 7 May 2011

23:50:07 +1000

MIME-Version: 1.0

Content-Type: text/plain

How To prioritize backups for virtualized Exchange 2010 servers

xchange Server 2010 includes a variety of policies throughout its infrastructure that limit and control storage. Sent and received message sizes can be limited; individual mailbox sizes can be limited. You can even limit mail and attachments coming from outside an Exchange organization.

Database backup and restore is another reason why controlling mailbox size is important to the health of your Exchange Server 2010 organization. As your databases grow, so does the amount of time you need for backup or restore, as well as any related task.

Exchange admins often focus more on the backup half of backup and restore. Yes, ensuring good backups is important; however, IT pros often spend too much time watching backups to complete and waste too much effort complaining that this process takes too long.

These activities are important for preserving data, but the most important metric actually has less to do with the time required to back up data than the time required to restore it. Restore time greatly factors into backups in a virtualized Exchange environment. This is especially true with Exchange 2010’s specialized databases.

Backups for your virtualized Exchange 2010 servers can live in several places:

1. On the mailbox server — From the mailbox server, backups occur much like traditional backups in a physical environment, offloading data to tape file-by-file. This process ensures that Exchange Server’s databases pause correctly so that they back up without data corruption. One problem you may run into is that agents installed here tend to put a strain on virtual environment performance during operation.

2. On the virtual host – From this location, the .VHD or .VMDK file becomes the backup unit. Here the backup agent must interact with another agent inside the VM to ensure the successful quiescence of Exchange’s databases. VHD and .VMDK backups are famous for simple point-in-time restore of entire VMs or databases. However, retrieving a single email or lost mailbox might require you to restore an entire database first, which can significantly increase restore time.
3. Servers outside the virtual environment — Encapsulating Exchange 2010 mailbox databases into .VHD or .VMDK files may create enormous files on disk, particularly when multiple databases are contained within a single disk volume. Configuring data partitions as raw disk mappings (RDMs), pass-through disks, or iSCSI connections keeps mailbox databases in a more raw format. With the correct tools, these files can be backed up directly from storage LUNs. The obvious concerns about proper database quiescence remain here.
4. On a"Backup 2.0" solution — These solutions gather backups through a file system filter driver located on the virtual host. Backup data is then deposited onto disk rather than tape. This approach reduces the storage requirements of backup while providing fast entire-server, entire-database or even single-item restore. While this is a relatively new approach, product options in this space are growing quickly. With this approach you may need to completely rethink — and potentially repurchase — your backup solution.

Unfortunately, none of these options completely solves the problem without additional cost, effort or performance degradation. To avoid making backup and restore mistakes when virtualizing Exchange, take a long look at what types of restores are important to you and how quickly you need those restores to complete.

For example, if entire database restorability is more important than restoring individual items in Exchange 2010, placing backups on virtual hosts or on servers outside your virtual environment (options two and three above) are your best bets.

Some businesses have decided that individual item restores are not an option. These environments prefer to designate more time before permanently removing deleted items. This prioritization is also useful for journaling and archive databases, where the preservation of all data is more important than individual item restorability.

Other Exchange organizations find that restoring individual email messages, mailboxes or calendar items is just as critical as protecting an entire Exchange database. Placing backups on your mailbox server or a backup 2.0 solution (options one and four above) provide the necessary functionality for these environments. Backups residing on the mail server leverage the tried-and-true interfaces of traditional backup solutions. A backup 2.0 solution trades those interfaces for added flexibility of what is being backed up.

Exchange Server 2010 Roles And Active Directory

Exchange Server 2010 Roles And Active Directory

Using Hub Transport Servers with Active Directory

Hub Transport contact Active Directory to perform the below functions:-

1.       Hub Transport performs message categorization. Categorizer queries Active Directory to perform recipient lookup, retrieves mailbox information and determine any recipient restrictions and permissions.

2.       Categorizer also queries Active Directory to expand the membership of Distribution lists.

3.       Hub Transport uses Active Directory site configuration information to determine the routing topology and the site in which mailbox is located.

If mailbox is located in a different Active Directory site, Hub transport delivers the message to a Hub Transport server in the remote Active Directory site.

Using Client Access Servers with Active Directory

When a user sends a request for a connection, CAS receives these requests and contacts Active Directory to authenticate and determine the locations of the user’s mailbox. If the user’s mailbox is in the same Active Directory site as the CAS, the user is connected to his/her mailbox. But if mailbox is located in the remote Active Directory site, the connection is redirected to a CAS in the remote Active Directory domain as the user’s mailbox.

Using Unified Messaging Servers with Active Directory

Unifies Messaging Servers contacts Active Directory to retrieve user’s global configuration information, such as dial plans, IP gateway details and so on. When a message is received by the Unified Messaging server, the server searches for Active Directory recipients to match the telephone number to a recipient address. When the server has resolved this information, it can determine the location of the mailbox and submit the message to the Hub Transport server.

Using Mailbox Servers with Active Directory

Mailbox servers contact Active Directory to determine the location of Hub Transport servers in their site and use this information for routing messages. Mailbox servers also store information about mailbox users/stores, address lists, recipient policies, mailbox policies, system policies and policies in Active Directory.

http://www.techpeoples.net/

Using Edge Transport Servers with Active Directory

Edge Transport server are deployed in a perimeter networks and do not have direct access to the organization’s internal domain. Unlike Hub Transport servers, Edge Transport servers cannot contact an Active Directory server to help route messages.

To route messages in to the internal domain, an administrator configures a subscription from Edge Transport to the Active Directory site that allows it to store recipient and configuration information about the Exchange organization. After an Edge Transport server is subscribed to an Active Directory site, it is associated with the Hub Transport servers in that site for the purpose of message routing. Thereafter, Hub Transport servers in the organization route messages being delivered to the Internet to the site associated with the Edge Transport server, and Hub Transport servers in this site relay the messages to the Edge Transport server. The Edge Transport server, in turn, routes the messages to the Internet.

http://www.techpeoples.net/

Article from articlesbase.com

Five Steps to Rebuild Exchange client access server

Most of the documentation  backing up Exchange Server 2007 and Exchange 2010 states that it isn’t necessary to back up your client access server (CAS). This makes sense because all of a client access server’s configuration information is stored in Active Directory. That said, you should still know how to rebuild a failed server.

If your CAS fails due to an irreparable hardware problem; follow these steps to repair it:

Reset the client access server’s computer account within the Active Directory Users and Computers console. Do not delete the account.

Install Windows on the new server and then install the same OS version as the failed server.

Rename the server to match the name the CAS used and join the server to your domain.

Depending on the version of Exchange Server and service pack you were running, insert the corresponding installation media into the server and run the following command:

Setup.com /M:RecoverServer

After the command runs, Setup will install the Exchange binaries and use the information stored in Active Directory to rebuild your CAS.

Note: This technique can also be used to rebuild any other Exchange Server roles, except for the edge transport server.

These steps work well to rebuild a failed client access server; however, there is a major caveat. This method only works if the server is running a standard configuration, which is unlikely since many organizations personalize their Outlook Web Access interface.

Using these steps will rebuild the CAS to a functional state, but any OWA customizations will be lost. This happens because Setup copies the Exchange binaries from the installation media, not your customized files.

Rebuilding a CAS and recovering OWA customizations
You have two options for recovering OWA customizations after rebuilding your client access server:

Perform a full server backup, then restore the entire server.

Make a backup of your customizations, then rebuild your CAS using the five step outline above. After that, you can restore your OWA customizations from backup.

In my environment, I only back up OWA customizations. In the event of a failure, my infrastructure is configured such that Exchange Setup rebuilds the CAS and then I manually restore customizations.

Although configuration information stored in Active Directory may change slightly, binaries on the server itself probably won’t change unless you install a patch or perform additional customizations.

Considering the static nature of a CAS, it’s tempting to make a full server backup and then store your backup in a fireproof vault. The only problem is that a full backup will quickly become outdated.

Windows periodically resets the password associated with Active Directory accounts, which gives your backup a limited shelf life. Depending on the version of Windows your CAS is running, the backup may only be relevant for 60 days. This happens because the password breaks synchronization with the password stored in the backup.

You can also reset the computer account password to use your backup, but it’s easier to back up only customizations. That way, you don’t have to worry about your backup becoming outdated — as long as you make a new backup with each additional customization.