Open Exchange management shell
New-OfflineAddressBook –name “OAB yshvili” –Addresslists “\Default Global Address List”
Get-OfflineAddressBook | Update-OfflineAddressBook
Get-OfflineAddressBook –Identity “oab yshvili” | fl
The case of failed Exchange & SQL backups when using VMware vSphere 6 and Veeam Backup & Replication 8
By: Netanel Ben-Shushan & Yaniv Totiashvili
In my case, I tried to take Exchange Server 2013 backups using Veeam Backup & Replication v8, or Veeam B&R 8 for short.
The Exchange Server 2013 is a virtual machine (VM) that’s running on top of VMware vSphere 6 environment.
When I tried to take backup of Exchange Server using Veeam B&R 8 I notice that the backup takes long time and at the end I get the following error at the Veeam-level:
"CBT (stands for Change Block Tracking) data is invalid, failing over to legacy incremental backup. No action is required, next job run should start using CBT again. If CBT data remains invalid, follow KB1113 to perform CBT reset. Usual cause is power loss."
At the Exchange Server-level I notice that some of the databases was at dismount state with no ability to mount them back correctly (some of the databases' transaction logs were corrupted after the backup completes), and I have to restore the databases manually from old valid backup or to use "Eseutil /P" to perform hard-recovery.
I contacted VMware support and they told me that I should contact Veeam support (The ping-pong method, LOL). I do so, and Veeam ask to me to wait for update 2 to be released. When Veeam B&R 8 Update 2 was released (download here), I installed it and try again to back up the Exchange with no luck.
During this time I've investigated in-depth this issue and found some issues regarding CBT at the VMware ESXi-level. I contacted VMware again and they released the following update that after installing it and performing Veeam back up again to the Exchange server make me sleep quietly.
More information about this issue can be found at VMware KB#2114076.
have removed the Client Access server (CAS) role and added the client access services to the Mailbox role. Even without the CAS role, the system maintains loose coupling in terms of functionality, versioning, user partitioning and geographical affinity.
The Mailbox server role now:
- Houses the logic to route protocol requests to the correct destination endpoint.
- Hosts all of the components and/or protocols that process, render and store the data.
No clients connect directly to the back-end endpoints on the Mailbox server; instead, clients connect client access services and are routed (via local or remote proxy) to the Mailbox server that hosts the active database that contains the user’s mailbox.
Mailbox servers can be added to a Database Availability Group (DAG), thereby forming a high availability unit that can be deployed in one or more datacenters. DAGs in Exchange Server 2016 do have a few specific enhancements:
- DatabaseAvailabilityGroupIpAddresses is no longer required when creating a DAG. By default, the failover cluster will be created without an administrative access point, as this is the recommended best practice.
- Replay Lag Manager is enabled by default.
- Lagged database copy play down can be delayed based on disk latency, thereby ensuring active users are not impacted.
- Database failovers times are reduced by 33% when compared to Exchange Server 2013.
Removal of the separate CAS role does not affect how communication occurs between servers. Communication between servers still occurs at the protocol layer, effectively ensuring that every server is an island. For a given mailbox’s connectivity, the protocol being used is always served by the protocol instance that is local to the active database copy.
Taken from the site of Thanks Team Blog
Try to moving mailbox from one DB to other
When we try to move requests mailbox in Exchange 2013 SP1 from one DB to other we need to with a long time and no success result.
Open Exchange Management Shell and type the command
New-MoveRequest -Identity "mailbox" -TargetDatabase DBDATANAME If you get the result the StatusDetail field changes to "StalledDuetoCI"
it sits here for hours on end Event ID: 1009 Event ID: 1010
1.Create a new Active Directory group that is named "ContentSubmitters"
and then grant Admistrators and NetworkService full access to the group
using the Security tab on the AD object. This is a dummy group and should
be used as a placeholder only. You might want to add a description so
that the group is not removed.
2.Force or wait for Active Directory replication.
3.Restart the following services:
Microsoft Exchange Search
Microsoft Exchange Search Host Controller
The second possible
disable the content index on the databases during the moves and then enable them after the moves are finished.
Disable the content index on the database as follows:
Set-MailboxDatabase "DBNAME" -IndexEnabled:$False
Enable the content index on the database as follows:
Set-MailboxDatabase "DBNAME" -IndexEnabled:$True