OAB/GAL not updating with new users

-Create new OAB on generating server
-Navigate to C:\Program Files\Microsoft\Exchange Server\ExchangeOAB and ensure there is a folder there -You may have to restart the Microsoft Exchange System Attendant service
-Go to Organization Configuration/Mailbox and Offline Address Book tab, make sure you are doing Web-Based distribution
-Navigate to your distribution servers to C:\Program Files\Microsoft\Exchange Server\ClientAccess\OAB and make sure the folder is there as well.  If it is not, restart the Microsoft Exchange File Distribution service and wait a bit.
-Go into IIS on the distribution servers, Application Pools, Recycle MSExchangeAutodiscoverAppPool
-In Outlook do an Test E-mail AutoConfiguration and ensure the OAB UID matches the folder name in the above directories

Unable to create storage group to many log files

As part of disaster recovery, I was trying to restore a database and 45,000 associated transaction logs.  I was getting the following error when trying to create a new storage group pointing to the restored data.
Failed to connect to the target server “MBX-05”. The exception message is “WMI exception occured on server ‘MBX-05’: Call cancelled “.

Exchange Management Shell command attempted:
new-StorageGroup -Server ‘MBX-05’ -Name ‘ Storage Group’ -LogFolderPath ‘F:\ExchangeGroups\StorageGroup\Logs’ -SystemFolderPath ‘F:\ExchangeGroups\StorageGroup\MailboxDatabase’

OST sync with mailbox after restore

If we restore Exchange 2007 data from 2 weeks ago and bring it back online, will Outlook clients sync the previous 2 weeks of email from the OST back to the Exchange mailbox after its restored from backup?

I seem to see split opinions on this, and no documentation to support either claim if it will or will not.

We just tested.  Outlook did not sync the previous 2 weeks of emails as I had thought back with Exchange.  However those 2 weeks of emails did stay put in the users Outlook so far…

relocating iSCSI volume with db/logs to a new server

We have an Exchange 2007 Mailbox server running on Server 2003. We want to build a Server 2008 box, and attach the Exchange iSCSI volume to the new server.


As with previous versions of Microsoft Exchange, an upgrade of the operating system for an Exchange server results in the updating of the value for OS Version in the database header. This update triggers the rebuilding of internal database indexes. When using database portability to move a database from a Mailbox server running Windows Server 2003 to a Mailbox server running Windows Server 2008, the Extensible Storage Engine (ESE) detects the operating system upgrade and takes the following actions:

  • During the first database mount operation, all secondary indexes are discarded. A secondary index is used to provide a specific view of the mailbox data (for example, when messages in a mail folder are sorted using Outlook in Online mode). The database will not be mounted and available to clients until this initial operation is complete. The amount of time to complete the operation is largely dependent on the size of the database. The larger the database is, the longer the mount operation will take.
  • Secondary indexes will be rebuilt on-demand as Outlook users sort their views in Online mode. In environments with large or extremely large databases, the on-demand rebuilding of indexes will initially result in high processor and disk utilization.

Unmount databases on old Exchange MBX server
Stop Exchange Services on old MBX server
Disconnect iSCSI volume from old MBX server
Connect iSCSI volume to new MBX server
Mount iSCSI drive in Windows on new MBX server
Create Storage Groups and point to existing DB/Logs on iSCSI volume
Mount databases
Wait for indexing to take place before database remounts
Run PowerShell command to point mailboxes from old MBX to new MBX

Get-Mailbox -database “EXMBX1\CORP Storage Group\Mailbox Database” | Move-Mailbox -TargetDatabase “EXMBX3\CORP Storage Group\Mailbox Database”| -ConfigurationOnly

4.4.2 Connection Dropped Exchange 2007

Had an issue with a couple users trying to send to 1 specific domain that just seemed to have stopped working.  Exchange queue on our Edge server was showing the following error: 4.4.2 Connection Dropped

After several hours of research, and determining it was nothing on our side, I contacted the other sides IT team who reached out to rackspace who was hosting their email.

Logs on Edge on our side showed the following

C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\Connectivity

2016-07-01T00:23:29.590Z,08D387F7316D769B,SMTP,domain.com,>,Established connection to XXX.XXX.XXX.XX1

2016-07-01T00:23:30.043Z,08D387F7316D769B,SMTP,domain.com,>,Established connection to XXX.XXX.XXX.XX2

2016-07-01T00:23:51.200Z,08D387F7316D769B,SMTP,domain.com,>,Failed connection to XXX.XXX.XXX.XX3 (0000274C)


Why was it establishing a connection, but moving onto the next MX record still?

Ran MX toolbox

Ran Microsoft Exchange Connectivity Analyzer which showed it wasnt able to connect to the 3rd MX record

Questioned what the 3rd MX record was, and it was a stale on-prem email record that was never removed.  They updated DNS to remove this.  Let it propagate the internet

Ran a ipconfig /flushdns on Edge server

Cleared the messages on the Edge server in this domains queue, Suspended the Queue, Resumed it to clear it out, sent another email and it went through successfully.

Cause: Stale MX record on recipients side

Conclusion: Only explanation I can come up with is that the first 2 MX records for rackspace were unavailable and it tried and hung onto the 3rd stale MX record and kept trying to use that.