Disk management console view is not up to date

I upgraded Exchange Management Tools by SP3 and RU10 (Exchange 2007) on a backup server and after server reboot I could not be able to start Exchange Management Shell. The shortcut did not refer to valid object. It seemed to be disk related issue and when I used Disk Management and saw the following:

30-06-2013 18-04-05

30-06-2013 15-42-08

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The operation failed to complete because the Disk Management console view is not up-to-date. Refresh the view by using the refresh task. If the problem persists close the Disk Management console, then restart Disk Management or restart the computer.

The problem was solved by disabling and enabling affected disks via Device Manager:

30-06-2013 18-41-26

30-06-2013 18-04-17

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Similar problems:

Exchange 2010 – DAG – Mapi network issue (MapiAccessEnabled, IgnoreNetwork)

One of our customers has ExRAAS ( Exchange health and remediation check service) every year to audit their environment for health, performance and MS best practices implementation. ExRAAS tools are developed every year and this years tool discovered very interesting issue about DAG networks.

Description:

Our customers DAG has 3 networks:

  • Production – meant to be client network, where only client traffic is enabled, replication traffic is disabled
  • Replication – not routable to MAPI network – custom 5Gbit bandwidth only for log replication
  • Backup – only for VSS backups, no MAPI nor replication traffic should flow there

Problem:

By design DAG is set, that Backup network should be ignored, however if I give Get-DatabaseAvailabilityGroupNetwork command, I can see MapiAccessEnabled parameter in $True, even though this network doesn´t have Clients for Windows Networks feature enabled and according to MS it is not supported network for clients. The magic starts when I set IgnoreNetwork to $false. Right after the change MapiAccessEnabled parameter is in correct value.

Get-DatabaseAvailabilityGroupNetwork DAG1\BACKUP | Set-DatabaseAvailabilityGroupNetwork -IgnoreNetwork $false
Get-DatabaseAvailabilityGroupNetwork | fl

RunspaceId         : 7d204cce-1dde-4e6f-9d52-cde8b238d2a9
Name               : BACKUP
Description        : VSS BACKUP Backup subnet - Ignored
Subnets            : {{172.24.188.0/24,Up}, {172.29.99.0/24,Up}}
Interfaces         : {{DC1MBX1,Up,172.24.188.108}, {DC1MBX2,Up,172.24.188.110}, {DC1MBX3,Up,172.24
                     .188.112}, {DC1PF1,Up,172.24.188.104}, {DC2MBX1,Up,172.29.99.109}, {DC2MBX2,U
                     p,172.29.99.111}, {DC2MBX3,Up,172.29.99.113}, {DC2PF1,Up,172.29.99.105}}
MapiAccessEnabled  : False
ReplicationEnabled : False
IgnoreNetwork      : False
Identity           : DAG1\BACKUP
IsValid            : True

RunspaceId         : 7d204cce-1dde-4e6f-9d52-cde8b238d2a9
Name               : MAPI
Description        : Production and possible replication
Subnets            : {{192.168.0.0/24,Up}}
Interfaces         : {{DC1MBX1,Up,192.168.0.108}, {DC1MBX2,Up,192.168.0.110}, {DC1MBX3,Up,192.168
                     .0.112}, {DC1PF1,Up,192.168.0.104}, {DC2MBX1,Up,192.168.0.109}, {DC2MBX2,
                     Up,192.168.0.111}, {DC2MBX3,Up,192.168.0.113}, {DC2PF1,Up,192.168.0.105}}
MapiAccessEnabled  : True
ReplicationEnabled : False
IgnoreNetwork      : False
Identity           : DAG1\MAPI
IsValid            : True

RunspaceId         : 7d204cce-1dde-4e6f-9d52-cde8b238d2a9
Name               : REPLICATION
Description        : Only replication
Subnets            : {{10.146.231.0/27,Up}}
Interfaces         : {{DC1MBX1,Up,10.146.231.24}, {DC1MBX2,Up,10.146.231.26}, {DC1MBX3,Up,10.146.2
                     31.28}, {DC1PF1,Up,10.146.231.20}, {DC2MBX1,Up,10.146.231.25}, {DC2MBX2,Up,10
                     .147.231.27}, {DC2MBX3,Up,10.146.231.29}, {DC2PF1,Up,10.146.231.21}}
MapiAccessEnabled  : False
ReplicationEnabled : True
IgnoreNetwork      : False
Identity           : DAG1\REPLICATION
IsValid            : True

When I change the Ignorenetwork back to $true, MapiAccessEnabled is set to $True as well.

Get-DatabaseAvailabilityGroupNetwork DAG1\BACKUP | Set-DatabaseAvailabilityGroupNetwork -IgnoreNetwork $true
Get-DatabaseAvailabilityGroupNetwork | fl

RunspaceId         : 7d204cce-1dde-4e6f-9d52-cde8b238d2a9
Name               : BACKUP
Description        : VSS BACKUP Backup subnet - Ignored
Subnets            : {{172.24.188.0/24,Up}, {172.29.99.0/24,Up}}
Interfaces         : {{DC1MBX1,Up,172.24.188.108}, {DC1MBX2,Up,172.24.188.110}, {DC1MBX3,Up,172.24
                     .188.112}, {DC1PF1,Up,172.24.188.104}, {DC2MBX1,Up,172.29.99.109}, {DC2MBX2,U
                     p,172.29.99.111}, {DC2MBX3,Up,172.29.99.113}, {DC2PF1,Up,172.29.99.105}}
MapiAccessEnabled  : True
ReplicationEnabled : False
IgnoreNetwork      : True
Identity           : DAG1\BACKUP
IsValid            : True

Conclusion:

This lead to errors in ExRAAS report and to question what is the right way. How should I behave to the network configuration? Better way is to set IgnorenNetwork parameter to $True and just ignore MapiAccessEnabled in $True. This article will be updated after I get info from MS for the resolution. It is also worth to mention, that last best practice says, that compression and encryption should be ENABLED on DAG replication network!

Links:

http://blogs.technet.com/b/schadinio/archive/2010/12/08/exchange-2010-mailbox-dag-based-practice-network-configurations.aspx

Exchange 2010 – MapiExceptionTooManyMountedDatabases

During a restore I was facing the following error so why not to mention it here.

Couldn't mount the database that you specified. Specified database: RDB2; Error code: An Active Manager operation failed. Error The database action f
ailed. Error: Operation failed with message: MapiExceptionTooManyMountedDatabases: Unable to mount database. (hr=0x8004060e, ec=-2147219954)

I already had an one recovery database mounted on server and it is reason for the error. Why? Because each Exchange 2010 or Exchange 2013 server allows for only one recovery database to be mounted at a time. The server can contain as many recovered databases as disk space allows, but only one can be mounted as the recovery database. The database mounted as the recovery database is counted in the maximum number of databases that can be mounted at a time. A recovered database mounted as a server’s recovery database is not associated with the original mailbox in any way (more).

Additionally, here is my procedure of the restore:

  1. New-MailboxDatabase -Recovery -Name RDB2 -Server EX2010 -EDBFilePath R:\RDB2\DB\RDB2.edb -LogFolderPath R:\RDB2\Logs
  2. Get-MailboxDatabase -Status| ft name, mounted, Recovery -a
  3. Backup Exec restore process (data restored into RDB, the database is mounted automatically)
  4. Get-MailboxDatabase RDB | Get-MailboxStatistics | ? {$_.DisplayName -like “*Pepa Novak*”}|fl
  5. New-MailboxRestoreRequest -name “Restore210613” -TargetMailbox kasajfilip -SourceDatabase “RDB2” -SourceStoreMailbox “Personal Archive – Pepa Novak” -BadItemLimit 100 -AllowLegacyDNMismatch -AcceptLargeDataLoss -targetrootfolder “Restore210613”
  6. Get-MailboxRestoreRequest -name Restore210613 | Get-MailboxRestoreRequestStatistics | fl
  7. New-MailboxExportRequest -name “Export210613” -Mailbox kasajfil -Include FoldersRestore210613/* -FilePath \\EX2010A\PSTfiles\PepaNovak(arch).pst
  8. Remove-MailboxDatabase RDB2
  9. Manually removing the database file

Exchange 2010 – AcceptMessagesOnlyFromSendersOrMembers and multivalued property syntax

I would like to show you one experience with multivalued property syntax.

My colleague was not able to modify the Message Delivery Restriction, concretely the Accept Messages From of a MailUniversalSecurityGroup. He added an user, applied settings and faced error below:

11-06-2013 16-26-03

 

 

 

 

 

 

 

 

--------------------------------------------------------
Microsoft Exchange Error
--------------------------------------------------------
The following error(s) occurred while saving changes:

Set-DistributionGroup
Failed
Error:
Couldn't find object "<identity>". Please make sure that it was spelled correctly or specify a different object.
--------------------------------------------------------
OK
--------------------------------------------------------

It is known issue which could occur for more mailbox attributes declaring security boundaries regarding users or groups. Basically it means that we cannot extend the Access Control till it contains an invalid object (e.g. mail-disabled group). In our case the invalid object is <identity> from the error above and its removing is necessary. The invalid object is not visible via Exchange Management Console and we has to use Exchange Management Shell. The invalid object is gathered in AcceptMessagesOnlyFrom or AcceptMessagesOnlyFromDLMembers multivalued attributes or certainly in AcceptMessagesOnlyFromSendersOrMembers (because it contains all values from both previous attributes) – more Set-DistributionGroup.

I wanted to remove the invalid object by action @{Remove=”<value1>”, “<value2>”} (remove one or more values from a multivalued property) – more Modifying Multivalued Properties. But as can be seen below the action was not supported for AcceptMessagesOnlyFromSendersOrMembers attribute (possible bug) and it removed all existing values (hopefully only one) without warning (tested Exchange 2010 SP2, SP3)! The modification of multivalued attributes AcceptMessagesOnlyFrom and AcceptMessagesOnlyFromDLMembers seemed to work properly. So be careful to use the multivalued property syntax every time.

11-06-2013 20-28-12I had a few affected MailUniversalSecurityGroups and I wanted to change = remove invalid objects Obj1-2 from AcceptMessagesOnlyFromSendersOrMembers attribute anyway so here is my procedure.

$groups = Get-Distribution MojeSkupiny*
foreach ($group in $groups){ 
 $ValidObjects = $Group | %{$_.AcceptMessagesOnlyFromSendersOrMembers}|?{$_.name -notlike "*Obj1*" -and $_.name -notlike "*Obj2*"}
 $Group | Set-DistributionGroup -AcceptMessagesOnlyFromSendersOrMembers $ValidObjects
}