In this article I want to talk about what happens when you let Exchange auto-create the DAG networks and you have DAG members in different subnets.  For example, suppose we have a two-node DAG stretched across two AD sites in different subnets.  After we create the DAG and add the two member servers, the network configuration will look something like this:

As you can see, we have one DAG network for each subnet.  Now let's assume you want to specify the 10.0.x.x networks for replication.  You would use the Set-DatabaseAvailabilityGroupNetwork cmdlet with the -ReplicationEnabled:$false parameter to disable replication on the "DAGNetwork01" and "DAGNetwork02" networks, which are on the 192.168.x.x subnets.

All done, right?  We now have replication set to use the 10.0.x.x networks and MAPI should be using 192.168.x.x.  We confirm that all routing is setup properly, so that there is no "crosstalk" between the networks.  (For example, the 10.0.2.0 network can't route traffic to the 192.168.1.0 network - only to 10.0.1.0).  However, now a new problem crops up.  When we try to seed a Mailbox Database Copy specifying either replication network, it fails with an error:

Notice the error message - "No available network interfaces exist."  What's happening here is that both nodes are trying to use network "DAGNetwork02" and that network only exists on one of the nodes.  DAGNetwork02 refers to the 10.0.1.0/24 subnet, which only exists on one node.  When the other node tries to use that network, it fails because it has no network interfaces on that subnet.  This is why the cmdlet fails with the same error no matter which network you specify.  As you might suspect, this means that seeding this way between DAG members in the same subnet will succeed, because they will each have a NIC on the specified subnet.

Now, the fix for this is really simple.  We just need to "collapse" the networks so they are grouped by their purpose.  We will create one new network for MAPI access and one for Replication use, specifying the networks for each purpose.  Here are the cmdlets I ran in my test lab:

New-DatabaseAvailabilityGroupNetwork -DatabaseAvailabilityGroup DAG1 -Name MAPI -Subnets 192.168.1.0/24,192.168.2.0/24 -ReplicationEnabled:$false

New-DatabaseAvailabilityGroupNetwork -DatabaseAvailabilityGroup DAG1 -Name Replication -Subnets 10.0.1.0/24,10.0.2.0/24

Now if we run Get-DatabaseAvailabilityGroupNetwork for the DAG, we see the new networks have been added and the subnets have moved to them:

 We still need to remove the auto-generated DAG networks, so we can do that with this cmdlet:

Get-DatabaseAvailabilityGroupNetwork DAG1\DAGNetwork* | Remove-DatabaseAvailabilityGroupNetwork

After confirming each deletion, the output of Get-DatabaseAvailabilityGroupNetwork looks like this:

If we retry seeding, specifying the "DAG1\Replication" network now, it succeeds:

The purpose of this article is really to make you aware that you must perform some manual configuration of your networks when you have a DAG with members in different subnets.  This should be a fairly common scenario as more enterprises deploy Exchange 2010, but is easy to miss or misunderstand.  I hope this is helpful to you in your deployment.

Here's a look at the Address share and the Everyone group's permissions on an Exchange 2010 server:

These shares go back to at least Exchange 4.0 and persist today in Exchange 2007.  In Exchange 2010 the Resources$ share is gone, but the Address share still exists.  This is apparently simply because no one has taken the time to remove them from the code.  The product group has not altered them in many years and has no current plans to do so.

This question usually comes from oganizations who have a security directive that mandates that permissions cannot be granted to the Everyone group.  To minimize your risk, you should be safe to remove the permissions for the Everyone group from the shares and grant Read permissions to the Authenticated Users group instead.  This will not change the effective permissions and will also satisfy your audit requirements.  This should also allow any 3rd party applications that access these shares to continue working.

This permissions change has not been tested and likely will not be tested by the Exchange product group, so I make no warranty that you will not have issues by doing so, but I find it extremely unlikely that you will.  Best of luck!

CCR and public folder replication are two very different forms of replication built into Exchange. Due to interoperability limitations between continuous replication and public folder replication, if more than one Mailbox server in the Exchange organization has a public folder database, public folder replication is enabled and public folder databases should not be hosted in CCR environments.

I wanted to take a few minutes to explain what can happen if you have a public folder database on a CCR cluster and you replicate it to another public folder server in your organization.  Keep in mind that if you have a public folder database on CCR and another public folder database in your environment, you will always be replicating between the two, even if you don't add replicas of your folders.  This is because the folder hierarchy of your public folder tree is replicated to all servers, even if the content of your data is not.

The issues you will run into will occur when there is an unexpected failover of your CCR.  There are three possible scenarios for CCR failover in regards to public stores mounting:

1.       Scheduled Failover.  If you move the CMS to the passive node via the GUI or via the Move-ClusteredMailboxServer command (and the Storage Groups are Healthy at the time), the public folder store will come online successfully.  This is assuming that there are no logs lost during the failover.

2.       Unscheduled Failover with no data loss.  In this scenario, the active node of the CCR goes down unexpectedly and the CMS fails over to the passive node automatically.  The public folder store will not mount in this scenario until the former active node is brought back online and all the logs for the storage group are available.  Once the first node is back online, you should be able to run Restore-StorageGroupCopy on the second node (now active) and then mount the Public Folder store.

3.       Unscheduled Failover with data loss.  This scenario is the same as #2, except in this case either the original active node is unrecoverable or its log data is lost due to disk corruption, etc.  Unfortunately, in this situation, you will not be able to mount the public folder store at all.  When the failover occurs, the following event will be logged on the newly active node when it attempts to mount the public folder database:

Log Name:      Application

Source:        MSExchangeRepl

Date:          4/2/2010 9:50:28 AM

Event ID:      2094

Task Category: Action

Level:         Warning

Keywords:      Classic

User:          N/A

Computer:      CCRnode2.contoso.com

Description:

Clustered Mailbox Server: CMS1

Physical Server: CCRnode2

Storage group CMS1\PF contains a public folder database that will not be automatically mounted because there was data loss.

 *The last log generated before the Move-ClusteredMailboxServer operation or failover was: 0

* The last log successfully replicated to the passive node was: 0

Attempts to copy to the last logs from the active node were not successful. Error code: The directory name \\CCRnode1\f4ce3b2b-b512-412b-ba09-131ed76090b1$ is invalid.

If you then attempt to mount the database manually from Exchange Management Shell, the following error will be returned:

[PS] C:\>mount-database pf

Mount-Database : Failed to mount database 'CMS1.contoso.com\pf' after a lossy failover occurred because of the current setting for AutoDatabaseMountDial. You must run Restore-StorageGroupCopy before you can mount the database.

This sounds logical, so let’s just run Restore-StorageGroupCopy as directed.  We’ll even add the –force switch since the source is not available.  Now we get:

[PS] C:\>Restore-StorageGroupCopy pf -force

Restore-StorageGroupCopy : Invalid operation for Restore-StorageGroupCopy. Reason: The specified storage group (PF) cannot be restored. The database will remain dismounted because it is a public folder database and public folder replication is enabled.

So now you can see that we cannot mount the database under any circumstances.  The only option at this point is to create a new storage group and public folder store on the CCR cluster.  To repopulate the database you could then either use public folder replication, or swap the original .edb file with the one for the new database.  As you can imagine, this is a lot of trouble to go through in the case of a single server failure.

The good news is that none of this occurs if you’re not doing public folder replication.  This is why the guidance is to either (A) Create only one public folder store for your entire organization on the CCR cluster or (B) House your public folder stores on non-clustered mailbox servers and enable public folder replication.  Either one is a valid scenario, and either one will give you redundancy.  The big questions to answer are whether your CCR can handle the user load from all your public folder users and also whether your users are geographically dispersed and need a local public folder server.

https://technet.microsoft.com/en-us/library/bb331973(EXCHG.80).aspx

A scenario that comes up less frequently is what to do in the case of a parent/child domain structure.  Aside from any Active Directory concerns, Exchange must have network access to domain controllers in the root domain of the forest.  This includes any Exchange tools being run from remote workstations.

Recently, we encountered a case where a customer had restricted network access from a client network so that they only had access to servers in a child domain of the forest.  Exchange was installed on servers in the child domain, so most functions worked appropriately.  The issue we found was in performing certain operations from the Exchange Management Console (“EMC”) from the clients that had no access to the root domain.  Certain functions in the EMC attempt to perform a connectionless LDAP (CLDAP) request to a domain controller in the forest root.  This is different from the Exchange Management Shell (“Shell”), which will connect to a local DC or GC (even in the child domain) to process its requests.

Here is an example from a NetMon capture I took while trying to create a mailbox from the EMC:

118  1.546875              192.168.12.2       192.168.10.2       CLDAP   searchRequest(1856) "<ROOT>" baseObject

130  1.546875              192.168.12.2       192.168.10.2       CLDAP   searchRequest(1857) "<ROOT>" baseObject

142  1.546875              192.168.12.2       192.168.10.2       CLDAP   searchRequest(1858) "<ROOT>" baseObject

150  1.546875              192.168.12.2       192.168.10.2       CLDAP   searchRequest(1859) "<ROOT>" baseObject

In my test, 192.168.12.2 is the client machine running the EMC and 192.168.10.2 is a domain controller in the forest root.  Since we never get a response from the DC, the operation eventually times out and fails.

Contrast this with a capture taken while doing the same thing (creating a mailbox) via the Shell:

6      0.000000              192.168.12.2       192.168.11.2       LDAP     alta-smp > ldap [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=350| searchRequest(43) "<ROOT>" baseObject

7      0.000000              192.168.11.2       192.168.12.2       TCP        [TCP segment of a reassembled PDU]

8      0.000000              192.168.11.2       192.168.12.2       LDAP     searchResEntry(43) "<ROOT>"

In this case, the Shell automatically selected a specific DC in the child domain (192.168.11.2), which is in a network that is accessible to the client.  You will also note that we used LDAP to connect, meaning a TCP session is established, whereas CLDAP would create a UDP session.

So, basically, this is just a difference in our code from the Shell to the EMC.  Another example you’ll see is when you try to specify a Configuration Domain Controller from the EMC versus the Shell.  To set it in the Shell, you would simply use this cmdlet:

$AdminSessionADSettings.ConfigurationDomainController = ‘server.domain.com’

From the Exchange Management Console, you must browse for a DC instead of specifying one:

Once you click the “Browse” button, EMC queries for the _ldap SRV record in the root domain and attempts to make a CLDAP connection to it, so you will see the same type of traffic in the trace as the one listed above.

The bottom line is that Exchange servers and any computers running the Exchange management tools must have network access to domain controllers and global catalogs in the root domain of the forest.  If you must restrict network traffic, you should place a GC from the root domain in the local subnet that is being restricted.

Using Windows Server Backup to Back Up and Restore Exchange Data

https://technet.microsoft.com/en-us/library/ee221172.aspx

Notice the last bullet point on this page, though:

"The plug-in does not support the Exchange Replica VSS Writer that is part of the Replication service. As a result, you cannot use Windows Server Backup to backup passive copies of storage groups."

Your first thought in reading this may be simply that you cannot backup the passive node of a Cluster Continuous Replication (CCR) cluster with Windows Server Backup.  However, this also applies to standalone servers that are Standby Continuous Replication (SCR) targets or that have Local Continuous Replication (LCR) enabled.  When Windows Server Backup processes a backup of a server with LCR or SCR enabled, it calls the VSS Writer from the Replication service instead of the VSS Writer from the Information Store service.  Since Windows Server Backup was not designed or tested for use with the Replication Service, the Exchange-aware portion of the backup fails.

The backup will complete, but you will see this error in the status window of the backup job:

The following error event will be logged in the Application Log:

Log Name:      Application
Source:        Microsoft-Windows-Backup
Date:          10/14/2009 8:44:53 AM
Event ID:      565
Task Category: None
Level:         Error
Keywords:     
User:          SYSTEM
Computer:      server1.domain.com
Description:
Consistency check for component '1a0a0e79-76ce-4985-aa99-35f5018b0ed7'\'Microsoft Exchange Server\Microsoft Information Store\SERVER1' failed. Application 'Exchange' will not be avaliable in the backup done at time '10/14/2009 8:44:42 AM'

RESOLUTION

In order to take an online Exchange-aware backup of a server using LCR or serving as an SCR target you must disable the Replica VSS Writer used by LCR.  To do so, follow these steps:

1.  Open Registry Editor and browse to the HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Replay\Parameters registry key.

2.  Add a new DWORD value named EnableVSSWriter and set the value to 0 (zero).

3.  Restart the Microsoft Exchange Replication Service.

This will allow Windows Server Backup to use the Microsoft Exchange Information Store service's VSS Writer to perform the backup.  You can confirm that the backup was successful by starting the Recovery Wizard in Windows Server Backup and verifying that you are able to select the Exchange application for recovery.

Just to clarify what a dial tone database is, this is a blank database you create to allow your users to send and receive new e-mails while a failed database is being recovered.  To create it, you simply move or rename the original database file (with a .edb extension) and then mount the database from EMC or EMS.  When the Information Store fails to find the .edb file in the specified location, you will be prompted to create a blank database.  If you agree, the dial tone database will be created.

For purposes of these instructions, let’s assume you have already created the dial tone database and are ready to restore the failed database from backup.

Create the Recovery Storage Group

To create the Recovery Storage Group,use the New-StorageGroup cmdlet, as follows: 

Note that we had to specify the Name of the storage group, as well as the path.  The system folder path contains the checkpoint file and the log folder path contains the transaction logs for the storage group.  I recommend making both the same.  The –Recovery parameter is necessary to make this storage group a Recovery Storage Group.

Create the RSG database

Now, we must add the database that we are going to recover.  Similar to creating the RSG itself, this is done by using the same cmdlet used to create a normal database, with an additional switch: 

The -MailboxDatabaseToRecover parameter specifies the database we are restoring.

Allow the database to be restored from backup

This should be set automatically when the database is added to the RSG, but just to be safe, I always run the cmdlet: 

Restore the database

You are now ready to proceed with restoring your database from backup.  Steps here will vary, depending on your software.  Once the restore is complete, you may choose to mount the database in the Recovery Storage Group: 

Once the RSG database is mounted, you can use Get-MailboxStatistics to confirm that the databases are present in this database (this information will not be listed by the Get-Mailbox cmdlet):

Swap the databases

Dismount the dial tone database and the RSG database using the Dismount-Database cmdlet, then swap the RSG database with the dial tone database by moving the files via Windows Explorer.  When you’re finished, the dial tone database will be in the RSG folder and the recovered database will be in the production folder that the dial tone database was previously in.  Your users will now have access to their old mail, but the newly received mail will be unavailable to them, since the database containing it is now in the Recovery Storage Group.  We do this swap so that when we merge the data from the two databases, the process will take the minimum amount of time.

Merge the databases

Of course, we have to mount the databases first, using the Mount-Database cmdlet .  To confirm that both databases are mounted, use this syntax:

Now that both database are mounted, you’re ready to merge the dial tone data back into the recovered database.  To  merge a single mailbox, use this syntax:

 Restore-Mailbox –Identity <username> -RSGDatabase <RSG db name>

More likely, though, you would like to select mailboxes in bulk to recover.  To do that, use this syntax:

Get-Mailbox –Database <production db name> | Restore-Mailbox –RSGDatabase <RSG db name>

For example: 

Notice that even though this is a bulk operation, we will be prompted for each mailbox individually.  In order to avoid this, just type A (for “Yes to All”) and press Enter here.

You will see the progress bar for multiple users as they are being restored: 

The EMS will display results for each user, but I find it much simpler to check the Application Log on the Exchange server to verify that each mailbox was successfully restored.  The event you’re looking for is as follows:

Cleanup

Once you are certain you have finished with the Recovery Storage Group, the best practice is to remove it.  The steps are as follows:

1.       Dismount with the Dismount-Database cmdlet.

2.       Remove the database, using this syntax:

Remove-MailboxDatabase –identity <Server_Name>\<RSG_Name>\<Database_Name>

3.       Remove the RSG, using this syntax:

Remove-StorageGroup –identity <Server_Name>\<RSG_Name>

I hope this helps to simplify the process if you’re ever in need of a dial tone database in Exchange 2007.

We see a similar result from the Test-ReplicationHealth cmdlet:

Oddly enough, though, the SummaryCopyStatus is Healthy for the storage groups in question, as shown in the results of the Get-StorageGroupCopyStatus cmdlet.  If we then check the CopyQueueLength via Performance Monitor, we find it looks normal:

Notice anything interesting here?  CopyQueueLength is at zero, as you might expect from a storage group in Healthy status, but notice the CopyGenerationNumber.  The value displayed here matches what we show as the CopyQueueLength from the Shell.  If we then take a look at the transaction log folder on the SCR target, we see that the last log copied matches this value (6151 decimal = 1807 hex):

This shows that our logs are copying successfully and we already know that our storage groups are in Healthy SummaryCopyStatus, so this indicates that we have an issue with the way CopyQueueLength is being calculated in the Exchange Management Shell.  This number is calculated by subtracting the Inspector Generation Number from the Latest Log Generation Number.  We see in the Perfmon counter above that Inspector Generation Number is correct, but for some reason we are still calculating it incorrectly.

So far, I have only seen this issue in a specific set of circumstances, which are easily reproduced, as follows:

1. Disable SCR by running Disable-StorageGroupCopy with the -StandbyMachine parameter.
2. Leave the database and logs for the storage group in place on the SCR target (in other words, do nothing).
3. Enable SCR by running Enable-StorageGroupCopy with the -StandbyMachine parameter, specifying the same SCR target as before.

You might do this in the real world if you wanted to change the ReplayLagTime parameter on the SCR copy of a storage group, since there is no other way to change it.  In this scenario, we would not initially be copying any logs from the SCR source, which seems to be causing the Microsoft Exchange Replication Service some sort of issue.  I have seen this issue correct itself over some time, once the ReplayLagTime has passed.  To resolve the issue right away, you can restart the Microsoft Exchange Replication Service on the SCR target.  The problem can be avoided altogether by deleting the database and logs from the SCR target so that the target is reseeded when you re-enable SCR.

As of now, there is no permanent fix to this issue, but it is continuing to be researched.

For more information on configuring Standby Continuous Replication, see this link:  Managing Standby Continuous Replication

The assumption is that User Five's free/busy info has become corrupted, but most people don't realize that the hashed lines will also be displayed if the user has no Calendar appointments during their publishing period.  By default, Outlook 2003 and prior publish 2 months of free/busy info, meaning the current calendar month and the next calendar month.  So, let's assume today is the 25th of the month.  If User Five has no items in his Calendar from the 1st of this month through the 31st of next month, other users will see hashed lines when trying to view his free/busy info.

Once User Five books an appointment, his info will be published by Outlook 2003 (and prior) within 15 minutes by default, or when he closes Outlook.  If the appointment is booked via OWA, free/busy info should be published right away.  Other Outlook clients will now see User Five's time represented as Busy, Out of Office, etc., depending on how he chose to display it from his Outlook client.

This article does an excellent job of detailing the free/busy publishing process:

https://msdn.microsoft.com/en-us/library/aa996946(EXCHG.65).aspx

Extended Free/Busy

While we're on the topic, I'd like to touch on Extended Free/Busy information.  This is the ability to see not just that User Five is busy during a certain time, but also to see what his Calendar appointment is for.  You see this by hovering over the block of time while on the Scheduling tab of your meeting.

This info is not displayed by default, though - you need to grant Reviewer permission on your Calendar to the users you want to share with:

You may want to set these permissions for all users on a team, so they can stay up to date with each other more easily.

Preventing New Contacts from Being Stamped

To prevent new contacts from being stamped by the Default Policy, you can simply create a new policy for contact objects and stamp them with a bogus SMTP address, as follows:

1.     Create a new Accepted Domain to correspond with the bogus SMTP address you will be using, e.g. "external.contact."  Here is the syntax to perfrom this step from Exchange Management Shell:

New-AcceptedDomain -Name "External Contact" -DomainName external.contact

2.     Create a new E-mail Address Policy for contact objects, using the SMTP address you just added:

New-EmailAddressPolicy -Name "Contact EAP" –EnabledPrimarySMTPAddressTemplate SMTP:@external.contact -IncludedRecipients MailContacts

3.     Confirm that the new policy has a higher priority than the Default Policy.  This will prevent the contacts from ever being stamped by the Default Policy.  The Default Policy should be set to "Lowest" priority, but you can confirm as follows:

Get-EmailAddressPolicy

You can also confirm this from the Exchange Management Console by clicking on Organization Configuration | Hub Transport in the Console Tree, then choosing the E-mail Address Policies tab from the Work Pane:

4.     Update the Address Policy in order to apply it to the existing Contact objects in the organization:

Update-EmailAddressPolicy -Identity "Contact EAP"

Removing the Internal Address from Existing Contacts

You can now remove the internal SMTP addresses from your existing contacts via a Powershell script.  Modify the following text, replacing contoso.com with your SMTP domain, and save it as a text file with a .ps1 extension.  (Make sure to remove any line breaks):

Get-MailContact -Filter {EmailAddresses -like "*@contoso.com" -and name -notlike "ExchangeUM*"} -ResultSize unlimited -IgnoreDefaultScope | foreach {$contact = $_; $email = $contact.emailaddresses; $email | foreach {if ($_.smtpaddress -like "*@contoso.com") {$address = $_.smtpaddress; write-host "Removing address"  $address "from Contact" $contact.name; $contact.emailaddresses -= $address; $contact | set-mailcontact -emailaddresspolicyenabled $false} }}

Now, open the Exchange Management Shell and change to the directory where your script is saved.  For example, if you have named the file RemoveContactSMTP.ps1, the syntax would be as follows:

./RemoveContactSMTP.ps1

You can accomplish the same thing using the ADModify tool, although it is a little more cumbersome:

1.     Download the ADModify.NET tool from codeplex.com:  https://www.codeplex.com/admodify

2.     After unzipping the files, run ADModify.exe and choose Modify Attributes.

3.     In the Domain List drop-down box, choose the item that identifies your domain.  This should be in the form DC=contoso,DC=com and NOT the one starting with CN=Configuration.

4.     In the Domain Controller List box, choose a DC.

5.     Uncheck all the boxes in the "Show Only" line except Contacts, then click the green arrow.  After you click the green button, the window should look like this:

6.  When your domain shows up in the Domain Tree List box, select it, then click the Add To List button.  You will get a warning that this will enumerate the entire domain.  Click OK to continue, or you may drill down to a specific OU if you prefer to limit the scope.

7.  Once the contacts have been enumerated in the right-hand pane, select the ones you wish to modify and click Next.

8.  Click the E-Mail Addresses tab, then select the checkbox next to Remove E-mail Address.  Edit the address to change "domain.com" to the internal SMTP domain you want to remove from the contact objects.  Click Go! to continue:

9.  Review the dialog that shows completion status, and click OK.

10. Rerun these steps on additional OUs as needed.

Once you have completed all steps, you should have no Contacts in your organization with internal SMTP addresses stamped on them, and new Contacts will not be stamped with them going forward.

One thing I've been finding in my cases is that many customers don't understand the Retention Period settings and how they are applied by the Managed Folder Assistant.  Let's take a look at a simple example to try and make this point.  Here is a typical mistake that many people make:

In this example, the Retention Period is set to start When item is moved to the folder.  Most of the time, people decide to choose this option because they want to apply the action to items that were either delivered to the folder or moved to the folder by the user 30 days ago.  When they add these settings to a policy and apply it, they are surprised to find that the items do not get archived.  The policy is actually working correctly in this case, but we need to understand what it is doing.

When you choose "When item is moved to the folder" as the start of the Retention Period, the retention period doesn't actually start until the next time the Managed Folder Assistant runs.  This is explained in the TechNet article regarding how Retention Periods are calculated:

https://technet.microsoft.com/en-us/library/bb430780.aspx

What the article does not explain is what the move date is.  The move date is actually a MAPI property named ElcMoveDate.  The "Elc" in ElcMoveDate stands for Exchange Lifecycle Assistant, another name for the Managed Folder Assistant.  This property is viewable by its property number (0x67170102) in MFCMapi:

This property will not be present at all until the Managed Folder Assistant has run on the folder and stamped the item.  The first time the Managed Folder Assistant runs, it stamps every item with the ElcMoveDate property and the current timestamp.  To clarify, this only applies to folders with Managed Content Settings set to  "When item is moved to the folder."  The Managed Folder Assistant will not delete any items at that point, unless there was somehow an existing item with an ElcMoveDate outside the retention period.  In subsequent runs, the Managed Folder Assistant will evaluate each item and determine if its ElcMoveDate is beyond the Retention Period.  If so, the Action specified by the Managed Content Settings for the folder will be taken.

Continuing the example from above, if the "Inbox 30 day retention" settings are applied to a user's mailbox, here is the sequence that would occur:

1.  Managed Folder Assistant runs for the first time on January 1 at 8:00am.  No items in the Inbox currently have an ElcMoveDate stamped, so all are stamped with the current date and time.

2.  Managed Folder Assistant continues to run daily for the next 29 days, moving no items.

3.  Managed Folder Assistant runs on January 31 at 8:00am.  All the items stamped on January 1 are now moved to the Deleted Items folder, because the ElcMoveDate is now 30 days in the past.

The confusion arises because there were very likely items in the Inbox on January 1 that were received or even moved there by the user in November, for example.  The administrator normally expects those items to be moved immediately.  Now you can see why this is not the case.

If you're looking to do archiving based on the date a message was received, you should choose  When delivered, end date for calendar and recurring tasks in the "Retention period starts" box.  When this is chosen, items are processed just as the setting implies:  everything except for Calendar items and recurring Tasks is processed based on message-received date.  Calendar items and recurring Tasks are processed based on the end date of the item.

Typically, the When item is moved to the folder setting is only placed on a folder that you are using as a Destination in your Managed Content Settings.  So, you would normally set the Inbox to start the retention process when items are delivered.  You would then set the Deleted Items folder to process based on when an item is moved to the folder.  This would allow you to have actual 30 day retention on the Inbox and allow, say, another 14 days once the item is moved to Deleted Items before it is permanently deleted.

Here again is a link to the TechNet article mentioned above.  Please review it carefully, as it explains in detail the rest of the retention period process: