Skip to main content
Sign In |
  Help (new window)
MMCUG Logo

MMCUG Blogs

Go Search
Home
MMCUG Blogs
Events
Event Registration
Directions
Sponsors
Links
LinkedIn
Search
  

> MMCUG Blogs > Categories

3/31/2009

How to Enable Redundant Exchange 2007 SP1 CCR Cluster Networks for Log Shipping and Seeding on Windows Server 2008

This article will discuss the optional configuration of how to enable redundant networks in a Server 2008 Failover Clustering scenario for supporting log shipping. Primary to this article is Exchange 2007 CCR nodes in a cluster and the configuration of setting up the public and private networks for supporting log shipping between the two CCR nodes.

By default, the private network carries only heartbeat traffic between the CCR nodes. The public network carries the log shipping or seeding traffic. To configure the private network to also support carrying the log shipping or seeding traffic, the following procedure will need to be performed.

The private network will need to be configured for "mixed network"; this is done using the EMS. A mixed cluster network is any cluster network that is configured for both cluster (heartbeat) and client access traffic. When a mixed cluster network has been configured, Microsoft Exchange Server 2007 uses that network for log shipping. Multiple mixed networks can be specified, and if more than one network is available, Exchange 2007 randomly selects one of the networks. If the network currently in use becomes unavailable, Exchange 2007 automatically selects another available network.

Article Node Configuration

For the purposes of this article, the following specifics are helpful to know when references are made:

CCR Names –

CCR Node Names: S08-E2k7-CCR1 and S08-E2k7-CCR2

CMS Name: CCRCMS

IP Addresses –

S08-E2k7-CCR1 Public: 10.10.10.1, Private: 192.168.1.1

S08-E2k7-CCR2 Public: 10.10.10.2, Private: 192.168.1.2

CCRCMS: 10.10.10.3

 

Name Resolution

On the adapter being configured for continuous replication traffic, name resolution must be configured specifically for the mixed network and NIC. Likely, the check box for the "Register this connection's address in DNS" has been cleared – and this is best practice for traditional cluster configurations. However, for CCR on Server 2008, either a static DNS entry for the new continuous replication host name or entries to the nodes' HOSTS file will be necessary to provide for name resolution.

NetBIOS name resolution is also necessary on the mixed network. The private NICs will likely have this disabled, as best practice from MS dictates. However, if NetBIOS name resolution isn't enable, the mixed network configuration will not support log shipping and/or seeding. If NetBIOS is not enabled, the Network Name resource will not come online, even if you enable NetBIOS for the adapter after the resource has been created. To resolve this issue, you must remove the cluster group and resources for the continuous replication host name, enable NetBIOS for the adapter, and then perform the following procedure.

Overview of the Entire Procedure

Follow the high level summary list below to configure the CCR nodes for Continuous Replication. Detailed steps supporting this high level list are presented below the summary.

  1. Create a new network host and IP address to support the mixed network.
  2. Enable NetBIOS on both private NICs.
  3. Create new entries in both CCR nodes' HOSTS file to resolve new backup name with new IP address.
  4. Configure the private network to support mixed or client access.
  5. Configure Windows Server 2008 for Alias name support via a registry change.
  6. Execute the Enable-ContinuousReplicationHostName cmdlet on nodes.
  7. Check status

A new network host and IP address must be established to support mixed networks. This is discussed in section 1.3 below

ContinousReplicationHostName Concept

In Exchange Server 2007 RTM, all operations (transaction log file copying and seeding) occurs over the Public network which is the same as used by the clients to access their data. In some cases if there are a higher number of log files to be transferred it might impact client performance. From a security perspective the log files are being transferred through the Public network and to secure this process we can use encryption that increases the performance of the servers involved.

After SP1, we can use one or more networks for log shipping, like the private network responsible for carrying the heartbeat traffic. We just need to associate a new hostname and new IP address to be used by the Replication service. If we have more than one redundant network available the service will pick one randomly to use. If one redundant network becomes unavailable the other redundant network will be selected. If none of the redundant networks are available the public network will be selected. The replication service discovery service runs every 5 minutes. As soon as an available redundant network is detected the replication will start to use the redundant network instead of the public network.

Prerequisites for deploying the Continuous Replication Hostname Support in Exchange 2007 SP1

Before creating the new hostnames and new IP address resources to be used we must make sure that some points are covered, such as:

  • Configure the network that will be used to replicate as a Mixed network in the Cluster Administrator. In Server 2008 this is labeled as "allow clients to connect through this network".
  • Configure Windows Server 2008 to be accessed through Alias names via a registry addition.
  • Configure name resolution to the new hostnames that can be done using host file entries.

Assuming our lab environment for this article, the current CCR network configuration can be seen in the first three columns of the table below. Let us assign a Continuous Replication Hostname and an IP Address for each node. Note: this IP address must be an address in the same range of the Private Network.

CCR Node/Host

Existing Config.

Public IP

Existing Config.

Private Heartbeat IP

Existing Config.

Continuous Replication Host Name

New Config.

Continuous Replication IP Address

New Config.

S08-E2k7-CCR1

10.10.10.1

192.168.1.1

CCRCR01

192.168.1.3

S08-E2k7-CCR2

10.10.10.2

192.168.1.2

CCRCR02

192.168.1.4

CCRCMS (CMS)

10.10.10.3

NA

NA

NA

 

Configuring the Private Cluster Network

Even though the private heartbeat network will not be accessed by external clients, it must be defined as mixed – or Allow clients to connect through this network.

To make this setting:

  1. Open Server 2008 Failover Cluster Management MMC.
  2. Expand the MS cluster, expand the Networks node and open the properties of the Private network node, as shown below.


 

3. Enable the checkbox as shown below for Allow clients to connect through this network, as shown below.


4. Click OK to complete this process. Perform the same procedure for the other CCR node.

Configuring Name Resolution

Each CCR node will need to contact the new host name that will be created for the private network. The new host names will be the following:

For Node – S08-E2K7-CCR1 – new additional host name of S08-E2K7-CCR1BKP

For Node – S08-E2K7-CCR2 – new additional host name of S08-E2K7-CCR2BKP

The new hostnames that will be created are the ones ending in the "BKP" characters. Each CCR node must be able to perform name resolution on the new name; for example, CCR node S08-E2K7-CCR1 must be able to resolve the new hostname of S08-E2K7-CCR2BKP which will be a new hostname for the other CCR node – and vice-versa. Because the private network cannot contact outside DNS, a HOSTS file entry will need to be made on each CCR node. This is shown below. (The "CRH" abbreviation stands for Continuous Replication Hostname.)

Accessing Windows Server 2008 through an Alias Name

In Windows Server 2008 a registry key must be added in all nodes of the CMS (Clustered Mailbox Server) to allow access through the alias name - by default this behavior is blocked.

Open the registry, and expand HKEY_LOCAL_MACHINE, System, CurrentControlSet, Services, LanManserver, Parameters. Then, right click on the right side and click on New, click on Dword Value, type in DisableStrictNameChecking, define the new value as 1. The result will be shown as below.

Perform this registry addition on the other CCR node as well. Reboot both CCR nodes to make the registry change complete.

Configuring the Continuous Replication Hostname Feature

The following procedure cannot be accomplished in any GUI tool; it must be performed by the EMS. To create the two new hostnames (one for each CCR node), execute the cmdlet Enable-ContinuousReplicationHostname on each node. The general syntax is:

Enable-ContinuousReplicationHostName -Identity <CMSName> -TargetMachine <NodeName> -HostName <NetworkNameforReplication> -IPV4Address <IPv4DottedDecimalIPAddress>

The exact syntax based on my lab is described below:

On Node S08-E2K7-CCR1:

Enable-ContinuousReplicationHostName –Identity CCRCMS –TargetMachine S08-E2K7-CCR1 –Hostname S08-E2K7-CCR1BKP –IPv4Address 192.168.1.3

On Node S08-E2K7-CCR2:

Enable-ContinuousReplicationHostName –Identity CCRCMS –TargetMachine S08-E2K7-CCR2 –Hostname S08-E2K7-CCR2BKP –IPv4Address 192.168.1.4

The two cmdlets will take some time to run; after successfully executed these cmdlets, you will see a new network group inside the Failover Cluster Manager tool. The two new groups will be called S08-E2K7-CCR1BKP_group and S08-E2K7-CCR2BKP_group. The two IP addresses used in the previous cmdlet will be associated with the two new groups as shown in the example figure below taken from an isolated lab environment. See the figure below for an example of the new objects in the Failover Cluster Management tool.

Check Status

To check the status of the new host names, execute the cmdlet Get-ClusteredMailboxServerStatus. We will be able to see that we have 4 (four) operational replication hostnames: two Continuous Replication HostNames (S08-E2K7-CCR1BKP and S08-E2K7-CCR2BKP) and two server names. At the moment only the Host Names S08-E2K7-CCR1BKP and S08-E2K7-CCR2BKP are being used to replicate the CMS data. This means that the replication is occurring through a redundant or private network.

Now, let us validate the replication using the Performance tool. We will open the tool in the second node and we will add the performance counter called Bytes Total/Sec. From the object Network Interface we will also add the two instances Network card 1 and 2. After sending a message of 4MB to a user located in the CMS server, we will be able to see that replication is using the backup network instead of the Public Network, as shown in the example figure below from a test environment.

 

Mark Myers

Senior Consultant

Project Leadership Associates

Posted at 8:32 PM by Mark Myers | Category: Exchange Server | Permalink | Email this Post | Comments (0)

3/23/2009

Continuous authentication prompts when using Outlook Anywhere on Windows Server 2008


When Exchange 2007 Service Pack 1 runs under Windows Server 2008, clients who connect to Exchange 2007 via Outlook Anywhere may be repeatedly prompted for their credentials. The problem occurs when NTLM authentication is enable as a supported method of authentication for Outlook Anywhere as well as is the selected authentication method in the Exchange Proxy Settings dialog box for the Outlook profile on the client computer.

The difference between Windows Server 2003 and Windows Server 2008 is that by default Kernel Mode Authentication is enabled in IIS 7.0 (Windows Server 2008) but not on IIS 6.0 (Windows Server 2003), to resolve this problem, we need to disable Kernel Mode Authentication on all Exchange 2007 Client Access Servers (CAS) that are running on Windows Server 2008.

To disable Kernel Mode Authentication on the Client Access Servers running on Windows Server 2008 perform the following steps:

  1. Open a command prompt window (Start – Run – cmd.exe )
  2. Change Directory to %systemroot%\system32\inetsrv\ (cd %systemroot%\system32\inetsrv\)
  3. Run the following command: AppCmd.exe set config /section:system.webServer/security/authentication/windowsAuthentication /useKernelMode:false

For more information about Exchange 2007 Outlook Anywhere visit http://technet.microsoft.com/en-us/library/bb123889.aspx

Jose Girbes
Senior Consultant
Project Leadership Associates

 

 

Posted at 5:47 PM by Jose Girbes | Category: Exchange Server | Permalink | Email this Post | Comments (0)

3/4/2009

Reducing the Cost of Your Email Migration with Quest Archive Manager

In the current economic climate, it's not surprising that all IT departments are looking to save on costs.  If you're presently looking at migrating a GroupWise or older Exchange system to Exchange 2007, you may be concerned with the time and resource cost of performing the migration and getting everything right.  Over the last several months, I've had customers express this very concern.  They want to convert/migrate to Exchange 2007, however, they just want it to be low cost, simple, and not a lot of user impact.  Which is typically easier said than done when you look at the task of moving gigabytes of email from older legacy systems to Exchange 2007.  Not only is the mailbox size a factor, but there are also GroupWise archives and/or Outlook .PST files to consider.

If you're migrating from GroupWise to Exchange 2007, chances are, you are already looking at using Quest Software's GroupWise Migrator for Exchange.  It is pretty much the defacto GroupWise migration tool.  If you're looking into an Exchange to Exchange migration (either intra-forest or inter-forest) you may have been looking at Quest Migration Manager for Exchange.

If you are using one of these tools, by adding Quest Archive Manager into the mix, you can greatly reduce the time and cost of your migration effort.   And, even if you're not using these tools, you can still use Quest Archive Manager to reduce your migration costs.

The methodology use for this approach is called "Archive before you Migrate" and is becoming one of the more popular migration scenarios.  To perform a migration using this method, you configure Archive Manager to use the existing legacy email system (GroupWise or Exchange 2003/2000) and being archiving all of your mail and import all applicable GroupWise archives and/or Outlook PST files.  Essentially, you want to pick a date and time to archive up to.  A good target example is 90-120 days and older email is placed into the archive.

Once all the older email is in the archive, you perform a standard migration, but filtered by date.  The big difference here is that you only migrate 90-120 days worth of email into Exchange 2007, rather than all the email that has been stored on your legacy system.  The older email is retained in Quest Archive Manager, and as mailboxes are migrated a process is done to reconnect the Archive Manager mailbox to the new Exchange 2007 mailbox.  Thus, instantly bringing all the legacy email content from the old system to the new system nearly instantaneously. 

The cost savings from doing this method can be quite significant, as Quest Archive Manager allows for the following:

  • Single instance storage across the Enterprise.  Messages in archive manager are only stored once per Archive Manager instance.
  • Ability to use low cost storage solutions for attachment data.  Archive Manager function extremely well on SATA drives and NAS solutions, as opposed to expensive Exchange 2007 SAN storage solutions
  • No client is required to access Archive Manager, as it is a web based application.  Therefore, a costly rollout to clients is not required.

 

This is just a short list that does not cover all Quest Archive Manager features, but simply highlights the big cost saving features for doing an "Archive before You Migrate" solution.  More information about Quest Archive Manager can be obtained from the Quest Software website at http://www.quest.com/archive-manager.

Eric Gentry
Senior Consultant
Project Leadership Associates

 

Posted at 12:05 PM by Eric Gentry | Category: Exchange Server | Permalink | Email this Post | Comments (0)

3/1/2009

Client RPC Dialog box questionnaire for Administrators
This blog provides a great link to download a Word document with a questionnaire users could fill out and return to an administrator to aid in troubleshooting RPC communication failures. Grab this one!
 
 
Mark Myers
Senior Consultant
Posted at 9:41 PM by Mark Myers | Category: Exchange Server | Permalink | Email this Post | Comments (0)
Make Text Files Specific to a Needed Size

Recently, I was testing SCR and CCR replication and needed to quickly create specific large-sized text files to be used as an attachment to mail messages. While there has to be thousands of ways to do this, one of the easiest ways is to uses the FSUtil utility. Get to a command prompt and enter the following:

FSUtil file CreateNew c:\new10MBFile.txt 10000000

The FSUtil utility will create a text file, based on my example, of 10MB in size, in the location specified. Now, simply use this file as your attachment to quickly fill up those 1MB log files you need for your testing.

Note – you must be logged on as a member of the Administrators group – or be an administrator - to use FSUtil.

Mark Myers

Senior Consultant

 

Posted at 4:20 PM by Mark Myers | Category: Exchange Server | Permalink | Email this Post | Comments (0)
Microsoft Exchange Server 2007 SP1 CCR Testing

I wanted to document the procedures to testing CCR failover scenarios. I wanted this procedure list to be short and easy – quick to execute to determine if the two CCR nodes were operating properly. The procedure with the Exchange Management Shell cmdlets is presented here. The procedures listed will work when using Windows Server 2003 or Windows Server 2008.

Assumptions

  • The two CCR nodes are called CCRNode1 and CCRNode2.
  • The CMS is called CMS

CCR Testing

Active node has E00.log; passive node only has E00.chk file – no E00.log on passive.

Public NIC Failure Test

This test simulates the failure of the public NIC on the active node.

  1. Connect to active node – CCRNODE1.
  2. Note presence of E00.log file on CCRNODE1. Passive node does not have E00.log file.
  3. Disable public NIC.
  4. Failover Clustering Manager shows resources going offline and moving to CCRNODE2 node.
  5. Execute Get-StorageGroupCopyStatus on machine with disabled NIC to see errors in not finding Active Directory DC. No client traffic now occurs over this public network – no users can access this node.
  6. Outlook clients can connect to mailbox on CMS now on CCRNODE2.
  7. Test inbound Internet mail to test mailbox on CMS.
  8. Enable public NIC on CCRNODE1.
  9. Issue Get-ClusteredMailboxServerStatus on CCRNODE1. Note it indicates CCRNODE2 is active. Issue same cmdlet from CCRNODE2 to verify it also shows it's the active node.
  10. Connect to CCRNODE2 to verify the presence of E00.log.

Note – state of databases may show as Initializing. What initializing is telling the administrator is that:  

  • The replication service has not received a notification to copy a log.
  • The replication service has not yet copied a log.
  • The replication service has not yet inspected a log.
  • The replication service has not placed a log out for replay and determined divergence information.

To change replication to a healthy state I usually do one of two steps: 

  1. Dismount and re-mount all databases -> this should cause log roll to occur and the replication service to replicate a log.
  2. Create test mailboxes in each store and send mail to them.  Mail flow will create log files.  If the mail flow is not significant enough to roll the logs, automatic log roll will occur at a later time even though the log file is not full.
  1. Perform a Move-ClusteredMailboxServer -id "CMS" -TargetMachine CCRNODE1 -MoveComment "Move CMS back to CCRNODE1 after public NIC testfailure"
  2. Verify the presence of E00.log on CCRNODE1, and that the E00.log file is not present on CCRNODE2 (now passive node).
  3. Perform these three standard tests:
    1. Test-ReplicationHealth
    2. Get-ClusteredMailboxServer
    3. Get-StorageGroupCopyStatus –ID CMS

      to validate all clustering and replication is healthy.

End of Public NIC Test

Private NIC Failure Test

This test simulates the failure of the private NIC on the active node.

  1. Verify CCRNODE1 node is active.
  2. Disable private NIC on active node.
  3. Issue the following standard test cmdlets and note the results:
  4. Get-ClusteredMailboxServer
  5. Get-StorageGroupCopyStatus –ID CMS
  6. Test-ReplicationHealth

Note the first two cmdlets show normal online and healthy status. The replication health result shows an error for the ClusterNetwork and an error on the private internal network, as expected.

  1. Re-enable private NIC on active node.
  2. Perform these three standard tests:
    1. Test-ReplicationHealth
    2. Get-ClusteredMailboxServer
    3. Get-StorageGroupCopyStatus –ID CMS

      to validate all clustering and replication is healthy.
  3. If the storage group does not come online, stop and start-ClusteredMailboxServer.
  4. Check Failover Cluster Manager for resources that may need to manually come online.
  5. Perform the standard three testing cmdlets once again to verify correct function.

End of Private NIC Test

Database Failure Test

This test simulates the failure of one of the mailbox databases on the active node.

  1. Verify CCRNODE1 is active.
  2. Dismount active node Store1.edb database simulating a database failure.
  3. CCR passive node CCRNODE2 will not provide service for this failed database – this is a manual recovery process involving the administrator back to the original active node. To simulate a real database failure, delete (or move) the SG1 logs and database files simulating a loss of logs and database files.
  4. A reseed from the passive copy to the active node is required. Suspend the copy process by executing the Suspend-StorageGroupCopy –id "EXCMS\sg1" cmdlet from the active node.
  5. Mount the database for SG1. Note the message regarding the creation of a new empty database.
  6. Execute the Update-StorageGroupCopy –id "CMS\sg1" –DeleteExistingFiles from the passive node. Note the warning message and choose to initiate and for possible reseeding of the checkpoint file. Note 2nd warning message and choose to initiate and for possible reseeding of the database.
  7. Perform these three standard tests:
    1. Test-ReplicationHealth
    2. Get-ClusteredMailboxServer
    3. Get-StorageGroupCopyStatus –ID CMS

      to validate all clustering and replication is healthy.


    End of Database Failure Test

Failed Information Store Service Test

This test simulates the failure of the Information Store service on the active node.

  1. Configure the information store service on CCRNODE1 (active node) for a startup type of Disabled, and then stop the service. If the service was simply stopped manually, it would be restarted automatically and no changes to service or nodes would occur and service would resume normally. But, in this case, its startup type is set to Disabled to prevent the auto-restart.
  2. Failover to CCRNODE2 to fully recover from failed service using Move-ClusteredMailboxServer –id CMS –TargetMachine CCRNODE2 –MoveComment "Comment here"
  3. Correct failed service on CCRNODE1. Restart service.
  4. Perform these three standard tests:
    1. Test-ReplicationHealth
    2. Get-ClusteredMailboxServer
    3. Get-StorageGroupCopyStatus –ID CMS

      to validate all clustering and replication is healthy.

 

  1. Failback to CCRNODE1 if desired with Move-ClusteredMailboxServer –id CMS –TargetMachine CCRNODE1 –MoveComment "Comment here".
  2. Perform these three standard tests:
    1. Test-ReplicationHealth
    2. Get-ClusteredMailboxServer
    3. Get-StorageGroupCopyStatus –ID CMS

      to validate all clustering and replication is healthy.

    End of Failed Information Store Service Failure Test

Active Node Failure Test

This test simulates the failure of the active node.

  1. Take CCRNODE1 active node offline completely.
  2. Note passive node CCRNODE2 comes online for the CMS for most or all resources. If CMS does not come online, try performing a Restore-StorageGroupCopy for that storage group. (Public folder will not come online – see bullet #4 below.
  3. If the previous cmdlet fails, execute Stop-ClusteredMailboxServer – then – Start-ClusteredMailboxServer.
  4. Verify in Failover Cluster Manager resource are online – manually attempt to bring any down online. For public folder storage group, it will never mount until original node is brought back online. For more information on public folders and CCR, see http://technet.microsoft.com/en-us/library/bb123996.aspx.
  5. To determine if databases have come online and have been mounted, execute Get-MailboxDatabase -status | ft name,storagegroup,mounted. This EMS cmdlet will return the database status much faster than using EMC.
  6. When the failed node comes online, check the following and make necessary corrections:
    1. Bring online the public folder resource/storage group.
    2. For any other database resources stuck in initialization state, attempt to Stop and Start-ClusteredMailboxServer to bring online.

    End of Active Node Failure Test

     

Mark Myers

Senior Consultant

Posted at 10:33 AM by Mark Myers | Category: Exchange Server | Permalink | Email this Post | Comments (0)

2/2/2009

Maintaining Replyability During a Migration

One of the largest hurdles to overcome during a messaging platform migration to Exchange is dealing with all the directory changes that occur on a consistent basis.  During a migration, a user record in Active Directory can change from a simple mail contact to a mail-enabled user account and then to a full Exchange 2007 mailbox in a number of days.  During all of these object changes, message delivery continues due to maintaining the same email address.

However, many customers that I've assisted with migrations notice that simple SMTP routing isn't enough.  When you change an object in AD that has had mail properties previously, then replies to messages to and from that object no longer work reliably, and the Outlook Name Cache also causes issues.  Even though all SMTP addresses are the same, it's as if the user is no longer there when replying to a message they may have just sent.

If this is occurring in your migration, then you most likely are missing a very important piece of a mail based AD object when changes are being made, the legacyExchangeDN attribute.  The legacyExchangeDN contains the X500 style address for a mail object in Active Directory.  When you change an object, or convert it to another object type (i.e mail-enabled user to mailbox-enabled user), you're generating a new X500 attribute, or legacyExchangeDN.  Since internally to Exchange and with the case of the Outlook Name Cache file, addressing is done primarily with this X500 address, you may get NDRs or errors sending to a user who has been modified overnight during a migration.

To combat this issue, you need to copy the legacyExchangeDN attribute to the newly modified object from its previous state.

As an example, let's review your garden variety Exchange migration scenario.  During directory synchronization from the source directory, a mail contact is created in the target AD for SMTP routing.  Even though the object is a contact, it has a legacyExchangeDN value. 

This user may exist on any system being migrated to Exchange from any other platform (GroupWise, Domino, or Exchange).  As part of the migration process, when this particular user (JWilson) is going to be migrated, the contact will typically be removed, and a AD user object created.  This object is then mailbox enabled, with all the proper SMTP addressing applied (as per below).

What isn't there is the previous legacyExchangeDN value from the Contact entry.  You may think that this entry isn't needed, however, if this value is not applied to the new mailbox, then replies to messages that appear to come from the contact may fail, and mail sent to this user which is pulled from another users Outlook Name Cache file results in an NDR.  This is primarily because the old value no longer exists in the directory.

To fix this issue, you need to append the former legacyExchangeDN value as an X500 type address.  Like the following:

You apply this address by putting the old legacyExchangeDN value into a custom X500 address.  This resolves both the reply issue and the Outlook Name Cache issue.  Appending this to your directory entries as they change during a migration is key to migration success, especially if your Exchange migration will have a protracted coexistence period.

Eric Gentry
Senior Consultant
Project Leadership Associates

 

Posted at 1:02 PM by Eric Gentry | Category: Exchange Server | Permalink | Email this Post | Comments (0)

1/8/2009

Journaling to an External Entity

Journaling contains confidential information, and therefore, must be transmitted securely. The following sections describe the recommended steps for configuring journaling to an external entity by various means.

 

Journaling to a Trusted Exchange Mailbox

In deployments where mail is journaled to a trusted Exchange mailbox in an Exchange organization, the journal mailbox should be locked down so that only journals that are generated by the Exchange Server can be sent to the archive. This method ensures that journaling is not spoofed. The following procedure describes the high-level steps that are required to lock down the journal mailbox:

1.     Create a journal mailbox on the Exchange server that you are using for journaling.

2.     To make sure that journaling is not spoofed, follow these steps to set permissions on the journal mailbox so that only Exchange Server can send to it.

·         In the Exchange Management Console tree, expand Recipient Configuration.

·         In the result pane, select the Journal Mailbox created.

·         In the Actions pane, click Properties, and then select the Mail Flow Settings tab.

·         Select Message Delivery Restrictions from the list of settings.

·         Add Microsoft Exchange to the senders.

·         Select the Require that all senders are authenticated check box.

3.     Hide the journal mailbox from the GAL by using the General tab on the Journal Mailbox Properties page.

4.     Set the journal mailbox as the destination in the journal rule.

Journaling to an External Organization

In deployments where journaling is sent to an external entity, such as an off-site archive vendor, organizations should ensure the following conditions:

  • Journaling is sent to the external archive over a secure, encrypted channel.
  • The off-site entity is locked down so that only journaling from partners are accepted.
  • The off-site archive is locked-down so that employees in an organization cannot spoof journaling.

The following procedure describes one method to help secure journaling to an external entity by using Exchange 2007.

1.    Configure routing in MyCompany.com to send journaling over a Send connector on which Transport Layer Security (TLS) is enabled. This should be configured only for the ExternalJournal.com address space.

2.    Configure ExternalJournal.com to accept messages from MyCompany.com over a Receive connector on which TLS is enabled.

3.    Create a contact in MyCompany.com that points to the journal mailbox in ExternalJournal.com.

4.    To make sure that journaling is not spoofed, follow these steps to set permissions on the contact so that only Exchange Server can send to it:

·         In the Exchange Management Console tree, expand Recipient Configuration.

·         In the result pane, select the Journal Mailbox created.

·         In the Actions pane, click Properties, and then select the Mail Flow Settings tab.

·         Select Message Delivery Restrictions from the list of settings.

·         Add Microsoft Exchange to the senders.

·         Select the Require that all senders are authenticated check box.

5.     Hide the journal mailbox from the GAL by using the General tab on the Properties page.

6.     Configure domain-secured e-mail between MyCompany.com and ExternalJournal.com.

7.     Create a contact in ExternalJournal.com for MyCompany.com.

a.    Set the contact’s address to MicrosoftExchange@MyCompany.com.

Set permissions on the journal mailbox so that only the contact created in the previous step can send to it.
 
Don Bacso
Senior Consultant
Project Leadership Associates
 
Posted at 9:12 AM by Don Basco | Category: Exchange Server | Permalink | Email this Post | Comments (0)

12/1/2008

Validating Input Data via PowerShell

I recently was helping a customer with a migration to Exchange 2007, and I had created several PowerShell scripts for them to help automate their migration.  Unfortunately, like most directories out there, they had some dirty data to contend with.  I ran into three distinct problems:

  1. I was having the user input a date for migration of specific users, the problem was, the date was not valid, and sometimes the users would put in "n/a" or "unknown".  The script really required a valid date input.
  2. For another value, I needed to check to see if a input was numeric or not.
  3. And lastly, some of the SMTP addresses I was given to apply to accounts were not valid. They contained invalid characters (spaces, etc) which are not permitted in SMTP addresses.

Validating Dates:

After doing some digging, I found that the "standard" Powershell for converting a string to a date is:

$datevalue = [datetime] $stringvalue

The problem with this, is that if $stringvalue is not really a good date, then your script will error that "it's not a valid date".  While that may seem logical, I really wanted a way to test this without having to do standard error trapping.  I remembered that when using VB scripting, I had the nifty "IsDate" function.  The benefit of "IsDate" is that you can feed it a string, and it will return whether or not the string can be a possible date (true or false).  This really is what I was looking for, but could really not find an equivalent function in PowerShell that was native.  However, I found you could call the VB script function by loading the VB Script assembly as such:

$migdate = "12/01/2008"
[reflection.assembly]::LoadWithPartialName("'Microsoft.VisualBasic")

$IsDate = [Microsoft.VisualBasic.Information]::isdate($migdate)

If (!$IsDate) {

Write-host "Value entered for MigrationDate is not a date, $migdate"

} else {

#continue processing with date

}

This allows you to do testing of dates before trying to convert them.


Validating Numbers:

Similar to "IsDate", VB script also had an "IsNumeric" function.  Rather than having to custom code an "IsNumeric" function for PowerShell, I decided to use the same VB Script assembly to test numbers as well:

$value = "not a number"

[reflection.assembly]::LoadWithPartialName("'Microsoft.VisualBasic")

$IsNumber = [Microsoft.VisualBasic.Information]::isnumeric($value)

If (!$IsNumber) {

Write-host "$value is not numeric"

}

Validating SMTP Addresses:

Now comes the tricky part.  Determining if an SMTP address meets the RFC can be tricky.  No matter what script language you use, you pretty much have to write an extensive amount of rules in order to check every possible variation.  Luckily, if you have Exchange 2007 in the environment, you can actually ask Exchange to use its own functionality to check the address for you, rather than writing yet another custom function.

Function Validate-EmailAddress {

param([string]$valemail)

[Microsoft.Exchange.Data.SmtpAddress]::IsValidSmtpAddress($valemail);

}

$PrimarySMTP = "This is not a valid SMTP address@contoso.com"

$ValidAddr = Validate-EmailAddress $PrimarySMTP

If ($ValidAddr) {

                Write-host "$Primary SMTP is valid"

}

This function actually sends the email address to Exchange to check validity.  It makes it a lot easier than writing your own custom parsing function.

Always Check Your Input:

When doing scripting it is always important to do validation on the data coming in, primarily if that data will be user entered.  These functions provide some quick shortcuts to validating your input data for those all important PowerShell scripts.

Eric Gentry
Senior Consultant
Project Leadership Associates 

 

Posted at 11:05 AM by Eric Gentry | Category: Exchange Server | Permalink | Email this Post | Comments (0)

11/30/2008

Calculating IOPS per Blackberry User using the Microsoft Exchange 2007 Mailbox Server Role Storage Requirements Calculator

I frequently receive the question from our clients as to what the predicted IOPS should be for a Blackberry user when this user will have a mailbox on Exchange 2007. This article is not written in judgment of which mobile email devices are better. Ideally clients will pick a Exchange 2007 centric solution using Exchange Activesync . However we know that many of our clients still prefer Blackberry's and as such we will continue to need to support these and calculate for their use. Thus it frequently becomes necessary to plan how these mobile users will affect the performance of the Exchange 2007 mailbox servers. The general accepted Input Output Operations per second (IOPS) for each Blackberry user is 3.64 additional IOPS per user as recommended in the reference "What Causes Exchange Disk I/O" . You should also reference "BlackBerry Enterprise Software v4.0 for Microsoft Exchange". The recommended IOPS for these users is frequently debated, but per Microsoft and RIM documentation 3.64 IOPS is the generally accepted measurement, which is something I will leave to others to debate.

So what formula should I use to calculate the overall IOPS per user when only some users will have Blackberry's . This formula could be expressed as follows.

("#of Exchange Mailbox Users"  *  "IOPS Profile / Mailbox") + ("# of Blackberry Users"  *  3.64) = Total IOPs

Thus a single blackberry user with 0.48 IOPS in cached mode could be calculated as

(1*0.48) + (1*3.64) = 4.12 IOPS for one user

1000 users with 0.48 IOPS / user with 500 of these users using a Blackberry could be predicted as such

(1000*0.48) + (500*3.64) = (480) + (1820) = 2300 Total IOPs for all users

So what is an easy way to place these calculations into the Microsoft Exchange 2007 mailbox Server role Storage Requirements Calculator found on the Microsoft Exchange Team Blog?

I recommend the following.

First determine your total number of Blackberry users. Let's assume 500. Now take your 500 users and multiple by 3.64.

500 * 3.64 = 1820

Place these IOPS in the "Additional I/O Requirement / Server" found on the Input Tab under IOPS Configuration of the Microsoft Exchange 2007 mailbox Server role Storage Requirements Calculator.

As such for a single mailbox server, LCR server, CCR or SCC cluster you would enter in the full 1820 IOPS into the Additional I/O Requirement / Server.

What if I wish to distribute my Exchange mailboxes and these Blackberry users over multiple mailbox servers, LCR servers, CCR or SCC clusters? Then you would divide the 1820 by the Number of Exchange Mailbox Servers you entered. In this example I entered 2 CCR clusters. Therefore I divided the 1820 additional IOPS needed by 2 and entered 910 IOPS in the Additional I/O Requirement / Server.

 

Forrest McDuffie
Senior Consultant
Project Leadership Associates

 

 

Posted at 8:14 PM by Forrest McDuffie | Category: Exchange Server | Permalink | Email this Post | Comments (0)
1 - 10 Next

Copyright © MMCUG - Midwest Messaging and Collaboration User Group 2008 Terms and conditions