• Office 365: Add an embedded link to an object in Outlook Web App

    Outlook Web App offers the ability for users to add hyper links to certain objects within a message.  Commonly this feature is utilize when converting a text statement to a particular URL.  To invoke this feature the message author would highlight a section of text and select the Insert HyperLink image  action on the toolbar.

     

    image

     

    This option may not be visible depending on the organization of the reading pane in OWA – you may need to press the menu expansion button image  to expose the Insert HyperLink button. 

     

    Message authors may desire to insert a link to an embedded image within a message.  In this example an image was inserted in the message. 

     

    image

     

    The embedded image was selected to allow a hyperlink to be inserted.  In this instance the insert hyperlink button is unavailable.

     

    image

     

    The insert hyperlink button is not available for embedded images.  Does that mean that an embedded image cannot have a hyperlink?  No – using keyboard shortcuts message authors can add a hyperlink to an embedded message.  Selecting the picture the message author can utilizing the shortcut CRTL + L.  Using this keyboard shortcut brings up the add hyperlink dialog.

     

    image

     

    A standard URL can be entered into this dialog and OK pressed to commit the hyperlink to the image.  When the message is sent to the recipient the hyperlinked image is included.  Clicking the image will allow the message recipient to go to the destination website specified.

     

    In a future revision of Office 365 the ability to utilize the add hyperlink button will be expanded to embedded images with Outlook Web App.

  • Office 365: Mail to deleted mail enabled user accounts results in NDR

    Customers may have users with a security principal within their domain that do not have a mailbox hosted within their messaging solution.  In this event customers choose to mail enable the user accounts.  In an Exchange environment mail enabled users accounts appear in the address list as if a local mailbox exists but mail destined for these objects are sent to the external email address stamped on the object.

     

    When using directory synchronization with Office 365 these objects are subsequently replicated into the MSOL directory as user accounts.  Exchange online then detects the presence of these mail enabled user accounts and subsequently creates a mail enabled user object in the Exchange Online directory.  This is what allows the user to appear in the Exchange Online address list.

     

    Let’s take a look at an example.

     

    In the on premises active directory a user account is provisioned.  This account is what allows for logon privileges to the domain.

     

    [PS] C:\>Get-User BlogTest

    Name                                                        RecipientType
    ----                                                        -------------
    Blog Test                                                   User

     

    The account is then mail enabled using the enable-mailUser commandlet.

     

    [PS] C:\>Enable-MailUser BlogTest -ExternalEmailAddress user@microsoft.com

    Name                                     RecipientType
    ----                                     -------------
    Blog Test                                MailUser

     

    Using the get-mailUser commandlet we can validate the settings of this user including the external email address set on the object.

     

    [PS] C:\>Get-MailUser BlogTest | fl externalemailaddress,userprincipalname,displayname,emailaddresses,primarysmtpaddress
    ,recipienttype

    ExternalEmailAddress : SMTP:user@microsoft.com
    UserPrincipalName    : BlogTest@domain.com
    DisplayName          : Blog Test
    EmailAddresses       : {smtp:BlogTest@domain1.domain2.com, smtp:BlogTest@serviceDomain.mail.onmicrosoft.com,
                           smtp:BlogTest@domain.com, SMTP:user@microsoft.com}
    PrimarySmtpAddress   : user@microsoft.com
    RecipientType        : MailUser

     

    When directory synchronization occurs the object can be validated in the MSOL directory using get-MSOLUser.

     

    PS C:\> Get-MsolUser -UserPrincipalName BlogTest@Domain2 | fl DisplayName,ProxyAddresses

    DisplayName    : Blog Test
    ProxyAddresses : {smtp:BlogTest@ServiceDomain.onmicrosoft.com, smtp:BlogTest@Domain2,
                     smtp:BlogTest@DOMAIN1.Domain2, smtp:BlogTest@ServiceDomain.mail.onmicrosoft.com...}

     

    When the provisioning process has had time to detect and operate on the object a mail user object is created in Exchange Online.  This can be validated with the get-MailUser command when connected to Exchange Online.

     

    PS C:\> Get-MailUser BlogTest | fl externalemailaddress,userprincipalname,displayname,emailaddresses,primarysmtpaddress,
    recipientType

    ExternalEmailAddress : SMTP:user@microsoft.com
    UserPrincipalName    : BlogTest@domain.com
    DisplayName          : Blog Test
    EmailAddresses       : {SMTP:user@microsoft.com, smtp:BlogTest@servicedomain.mail.onmicrosoft.com,
                           smtp:BlogTest@domain1.domain2.com, smtp:BlogTest@domain.com...}
    PrimarySmtpAddress   : user@microsoft.com
    RecipientType        : MailUser

     

    At this time the object is fully provisioned and will appear in the Exchange Online global address list.  Users who select this object from the global address list will successfully send email to the remote mailbox.

     

    image

     

    image

     

    There may exist at some time a reason to remove the on premises Active Directory user account.  When this object is removed and directory synchronization is performed this should result in the removal of the MSOL user account as well as the mail user account within Exchange Online.  Let’s look at an example.

     

    Using Active Directory Users and Computers the on premises AD object is deleted.  This can be validated with Get-User.

     

    [PS] C:\>Get-User BlogTest


    The operation couldn't be performed because object 'BlogTest' couldn't be found on 'Server1.domain.domain.com'.
        + CategoryInfo          : NotSpecified: (:) [Get-User], ManagementObjectNotFoundException
        + FullyQualifiedErrorId : [Server=MAIL,RequestId=95b95c5e-03c2-406a-9400-c490c0d7cddb,TimeStamp=5/13/2014 1:34:34PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 4549B0D2,Microsoft.Exchange.Management.RecipientTasks.GetUser
        + PSComputerName        : mail.domain.domain.com

     

    This also results in the removal of the on premises mail user object.  This can be validated with Get-MailUser.

     

    [PS] C:\>Get-MailUser BlogTest


    The operation couldn't be performed because object 'BlogTest' couldn't be found on 'Server1.domain1.domain2.com'.
        + CategoryInfo          : NotSpecified: (:) [Get-MailUser], ManagementObjectNotFoundException
        + FullyQualifiedErrorId : [Server=MAIL,RequestId=0106f632-ad95-4f07-b054-4e749e437cfc,TimeStamp=5/13/2014 1:35:55PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 84EC86F5,Microsoft.Exchange.Management.RecipientTasks.GetMailUser
        + PSComputerName        : mail.domain1.domain2.com

     

    When directory synchronization has completed we can validate the object no longer exists in the MSOL directory using get-MSOLUser.

     

    PS C:\> Get-MsolUser -UserPrincipalName BlogTest@domain2.com | fl DisplayName,ProxyAddresses


    Get-MsolUser : User Not Found.  User: BlogTest@domain2.com.
    At line:1 char:1
    + Get-MsolUser -UserPrincipalName BlogTest@domain2.com | fl DisplayName,Pro ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : OperationStopped: (:) [Get-MsolUser], MicrosoftOnlineException
        + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.UserNotFoundException,Microsoft.Online.Administration.Automation.GetUser

     

    When the provisioning process has detected the deletion the mail user object is removed from Exchange Online.  This can be validated with get-MailUser.

     

    PS C:\> Get-MailUser BlogTest


    The operation couldn't be performed because object 'BlogTest' couldn't be found on 'CO1PR06A002DC02.NAMPR06A002.prod.outlook.com'.
        + CategoryInfo          : NotSpecified: (:) [Get-MailUser], ManagementObjectNotFoundException
        + FullyQualifiedErrorId : [Server=BN1PR06MB101,RequestId=c3cde9d7-e638-4808-8891-65d539689698,TimeStamp=5/13/2014 1:40:19 PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 782EAA9B,Microsoft.Exchange.Management.RecipientTasks.GetMailUser
        + PSComputerName        : pod51043psh.outlook.com

     

    The object after deletion from the Exchange Online directory will no longer appear in the address list. 

     

    image

     

    End users who desire to email this object would have to address the message manually to the external email address.  For example:

     

    image

     

    This is where the issue arises.  In this instance the user has successfully addressed an email to the external email address but the mail is returned with a non-delivery report.

     

    image

     

    Delivery has failed to these recipients or groups:

    Blog Test

    The email address you entered couldn't be found. Check the recipient's email address then try to resend the message. For more tips to resolve this issue see DSN code 5.1.1 in Exchange Online. If the problem continues contact your help desk.

     

    The diagnostic information states the following:

     

    Diagnostic information for administrators:
    Generating server: DM2PR0601MB0953.namprd06.prod.outlook.com
    IMCEAEX-_o=ExchangeLabs_ou=Exchange+20Administrative+20Group+20+28FYDIBOHF23SPDLT+29_cn=Recipients_cn=0729272369574e7d945aeeecf1afd94c-Blog+20Test@namprd06.prod.outlook.com
    Remote Server returned '550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found'
    Original message headers:

    Received: from DM2PR0601MB0953.namprd06.prod.outlook.com (25.160.25.145) by
    DM2PR0601MB0953.namprd06.prod.outlook.com (25.160.25.145) with Microsoft SMTP
    Server (TLS) id 15.0.944.11; Tue, 13 May 2014 13:43:53 +0000
    Received: from DM2PR0601MB0953.namprd06.prod.outlook.com ([25.160.25.145]) by
    DM2PR0601MB0953.namprd06.prod.outlook.com ([25.160.25.145]) with mapi id
    15.00.0944.000; Tue, 13 May 2014 13:43:53 +0000
    Content-Type: application/ms-tnef; name="winmail.dat"
    Content-Transfer-Encoding: binary
    From: Dev User <DevUser@servicedomain.onmicrosoft.com>
    To: Blog Test <user@microsoft.com>
    Subject: Test Message
    Thread-Topic: Test Message
    Thread-Index: AQHPbrFT/8JoaY496EePsUIz8dp/Tw==
    Date: Tue, 13 May 2014 13:43:52 +0000
    Message-ID: <1399988632393.9363@FortMillRescueSquad.onmicrosoft.com>
    Accept-Language: en-US
    Content-Language: en-US
    X-MS-Has-Attach:
    X-MS-TNEF-Correlator: <1399988632393.9363@servicedomain.onmicrosoft.com>
    MIME-Version: 1.0
    X-Originating-IP: [167.220.151.116]
    Return-Path: DevUser@serviceDomain.onmicrosoft.com

     

    For many administrators this NDR is recognizable.  The same NDR is generated when an object is deleted from the environment but the email is addressed using nickname or recipient cache.  In this instance though the email was not addressed using nickname or recipient cache but rather the SMTP address was fully typed in the TO: line.  (Note:  The email address was manually removed from the nickname cache prior to addressing the email to ensure that automatic resolution does not occur.)

     

    Why is the mail NDRing.  When a user account is removed from the MSOL directory the account is placed into a soft deleted state.  This can be validated with get-MSOLUser –returnedDeletedUsers.

     

    PS C:\> Get-MsolUser -UserPrincipalName BlogTest@domain.com -ReturnDeletedUsers

    UserPrincipalName                       DisplayName                             isLicensed
    -----------------                       -----------                             ----------
    BlogTest@domain.com                     Blog Test                               False

     

    While the user remains in a soft deleted state within the MSOL directory the corresponding mail user object remains in a soft deleted state within Exchange Online.  It is believed that the recipient resolvers within transport detect the presences of the soft deleted mail user object within the Exchange Online directory and subsequently produce a non-delivery report based on the state of this object.

     

    This mail is legitimate though – how can the issue be resolved?

     

    In order to remove the soft deleted mail user object from the Exchange Online directory the soft deleted user object must be removed from the MSOL directory.  This can be accomplished with remove-MSOLUser.

     

    PS C:\> Remove-MsolUser -UserPrincipalName BlogTest@domain.com -RemoveFromRecycleBin

    Confirm
    Continue with this operation?
    [Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): y

     

    The results can be validated with Get-MSOLUser.

     

    PS C:\> Get-MsolUser -UserPrincipalName BlogTest@domain.com -ReturnDeletedUsers
    Get-MsolUser : User Not Found.  User: BlogTest@fortmillrescue.com.
    At line:1 char:1
    + Get-MsolUser -UserPrincipalName BlogTest@fortmillrescue.com -ReturnDeletedUsers
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : OperationStopped: (:) [Get-MsolUser], MicrosoftOnlineException
        + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.UserNotFoundException,Microsoft.Online.Administration.Automation.GetUser

     

    The provisioning process will eventually detect the deletion of the object from the MSOL directory.  This will cause the soft deleted mail user object to be purged from the Exchange Online directory.  After this object is purged mail should deliver successfully to the external account when the full external email address is utilized.

     

    image

     

    At this time anytime a mail user object is removed from the on premises directory the corresponding soft deleted MSOL object would need to also be removed in order to ensure that mail addressed to the external object will immediately function.  In many cases the soft deleted MSOL object will expire, resulting in the removal of the soft deleted mail user object from the Exchange Online directory, prior to this issue being noticed by the end user population.

     

    Our development teams are aware of this behavior and are considering potential future service modifications.

  • Exchange 2010 / 2013: What constitutes a failure of the replication network…

    In both Exchange 2010 and Exchange 2013, customers can deploy one or more replication networks in a database availability group (DAG).  There can be many reasons for using a replication network, but in most cases they are used to provide a dedicated log shipping channel between members of the same DAG.

     

    As documented on TechNet, when a replication network fails, replication should automatically failover to the DAG’s MAPI network:

    · http://technet.microsoft.com/en-us/library/dd638104(v=exchg.150).aspx (Exchange 2013)

    · http://technet.microsoft.com/en-us/library/dd638104(v=exchg.141).aspx (Exchange 2010)

     

    In the event of a failure affecting the Replication network, if the MAPI network is unaffected by the failure, log shipping and seeding operations will revert to use the MAPI network, even if the MAPI network has it's ReplicationEnabled property set to False.

     

    Log shipping operations occur by connecting to the Microsoft Exchange Replication service on the server that hosts the active database copy, on TCP port 64327 using a random ephemeral port on the passive server.  Log files are then pushed from the active server to the passive server via this channel.  There can exist several issues that result in this log shipping channel being interrupted.  For example, a firewall may block port 64327, static routes may be missing on multi-subnet replication networks, or an intermediary network device may not route traffic correctly. 

     

    In the following example, we have a 4-member DAG running Exchange 2013.  There is a single active database that is replicated to three other servers.

     

    image

     

    The DAG has two networks that each has two subnets.  These networks represent the MAPI and Replication networks for the DAG.  Automatic network detection in Exchange 2013 was disabled for this example.

     

    RunspaceId         : 60e6ae0f-e69d-4ae6-9fcb-8c99ea9fd21f
    Name               : MapiDagNetwork
    Description        :
    Subnets            : {{192.168.0.0/24,Up}, {192.168.1.0/24,Up}}
    Interfaces         : {{MBX-1,Up,192.168.0.11}, {MBX-2,Up,192.168.0.12}, {MBX-3,Up,192.168.1.11},
                         {MBX-4,Up,192.168.1.12}}
    MapiAccessEnabled  : True
    ReplicationEnabled : True
    IgnoreNetwork      : False
    Identity           : DAG\MapiDagNetwork
    IsValid            : True
    ObjectState        : New

    RunspaceId         : 60e6ae0f-e69d-4ae6-9fcb-8c99ea9fd21f
    Name               : ReplicationDagNetwork01
    Description        :
    Subnets            : {{10.0.1.0/24,Up}, {10.0.0.0/24,Up}}
    Interfaces         : {{MBX-1,Up,10.0.0.1}, {MBX-2,Up,10.0.0.2}, {MBX-3,Up,10.0.1.1}, {MBX-4,Up,10.0.1.2}}
    MapiAccessEnabled  : False
    ReplicationEnabled : True
    IgnoreNetwork      : False
    Identity           : DAG\ReplicationDagNetwork01
    IsValid            : True
    ObjectState        : New

     

    Using Get-MailboxDatabaseCopyStatus with the –ConnectionStatus switch, we can verify that the Replication network is currently in use:

     

    [PS] C:\>Get-MailboxDatabaseCopyStatus * -connectionStatus | fl name,incominglogcopyingnetwork,outgoingconnections

    Name                      : DAG-DB0\MBX-1
    IncomingLogCopyingNetwork :
    OutgoingConnections       : {}

    Name                      : DAG-DB0\MBX-2
    IncomingLogCopyingNetwork : {MBX-1,ReplicationDagNetwork01}
    OutgoingConnections       :

    Name                      : DAG-DB0\MBX-3
    IncomingLogCopyingNetwork : {MBX-1,ReplicationDagNetwork01}
    OutgoingConnections       :

    Name                      : DAG-DB0\MBX-4
    IncomingLogCopyingNetwork : {MBX-1,ReplicationDagNetwork01}
    OutgoingConnections       :

     

    The router servicing the network link between the two subnets of the Replication network is shutdown.  This will block replication from succeeding over the Replication network.  What happens to the database copies?

     

    [PS] C:\>Get-MailboxDatabaseCopyStatus * | fl name,status

    Name   : DAG-DB0\MBX-1
    Status : Mounted

    Name   : DAG-DB0\MBX-2
    Status : Healthy

    Name   : DAG-DB0\MBX-3
    Status : DisconnectedAndHealthy

    Name   : DAG-DB0\MBX-4
    Status : DisconnectedAndHealthy

     

    In this example, the database copies enter a DisconnectedAndHealthy state.  Reviewing the connection status, we note that the connection has timed out between the servers; this is expected since the route is down.

     

    [PS] C:\>Get-MailboxDatabaseCopyStatus * -ConnectionStatus | fl name,incominglogcopyingnetwork,outgoingconnections

    Name                      : DAG-DB0\MBX-1
    IncomingLogCopyingNetwork :
    OutgoingConnections       : {{MBX-2,ReplicationDagNetwork01}}

    Name                      : DAG-DB0\MBX-2
    IncomingLogCopyingNetwork : {MBX-1,ReplicationDagNetwork01}
    OutgoingConnections       :

    Name                      : DAG-DB0\MBX-3
    IncomingLogCopyingNetwork : {MBX-1,,A timeout occurred while communicating with server 'MBX-1'. Error: "A connection
                                could not be completed within 15 seconds."}
    OutgoingConnections       :

    Name                      : DAG-DB0\MBX-4
    IncomingLogCopyingNetwork : {MBX-1,,A timeout occurred while communicating with server 'MBX-1'. Error: "A connection
                                could not be completed within 15 seconds."}
    OutgoingConnections       :

     

    Why didn’t the Replication network failover to the MAPI network in this case?  For one thing, the ability to establish a log shipping channel is not one of the criteria that the Replication service uses to determine the health of a given network.  The Replication service relies on feedback from the Cluster service regarding individual network interface status in order to determine the health of a log shipping channel.

     

    For each subnet that exists on a DAG member, an associated cluster network is created.  In this example, there are 4 subnets and therefore there are 4 cluster networks.

     

    [PS] C:\>Get-ClusterNetwork | fl

    Name  : Cluster Network 1
    State : Up

    Name  : Cluster Network 2
    State : Up

    Name  : Cluster Network 3
    State : Up

    Name  : Cluster Network 4
    State : Up

     

    image

     

    The interface associated with each of these subnets is included in the appropriate cluster network.  Each of these interfaces has a status based on status reporting in Windows Failover Clustering.

     

    [PS] C:\>Get-ClusterNetworkInterface | fl

    Name    : MBX-1 - LAN-A
    Node    : MBX-1
    Network : Cluster Network 1
    State   : Up

    Name    : MBX-2 - LAN-A
    Node    : MBX-2
    Network : Cluster Network 1
    State   : Up

    Name    : MBX-1 - REPL-A
    Node    : MBX-1
    Network : Cluster Network 2
    State   : Up

    Name    : MBX-2 - REPL-A
    Node    : MBX-2
    Network : Cluster Network 2
    State   : Up

    Name    : MBX-3 - REPL-B
    Node    : MBX-3
    Network : Cluster Network 3
    State   : Up

    Name    : MBX-4 - REPL-B
    Node    : MBX-4
    Network : Cluster Network 3
    State   : Up

    Name    : MBX-3 - LAN-B
    Node    : MBX-3
    Network : Cluster Network 4
    State   : Up

    Name    : MBX-4 - LAN-B
    Node    : MBX-4
    Network : Cluster Network 4
    State   : Up

     

    image

     

    In this scenario, the Cluster service considers all of the interfaces as “UP.”  Since the interfaces are UP, the Replication service does not failover to the MAPI network even though replication cannot occur over the replication network. 

     

    If the Cluster service reports a network as “FAILED” the behavior is different.  On a server hosting a passive database copy, the network cable was removed from the Replication network interface, causing the cluster to mark that interfaces as failed:

     

    [PS] C:\>Get-ClusterNetworkInterface | fl

    Name    : MBX-1 - LAN-A
    Node    : MBX-1
    Network : Cluster Network 1
    State   : Up

    Name    : MBX-2 - LAN-A
    Node    : MBX-2
    Network : Cluster Network 1
    State   : Up

    Name    : MBX-1 - REPL-A
    Node    : MBX-1
    Network : Cluster Network 2
    State   : Up

    Name    : MBX-2 - REPL-A
    Node    : MBX-2
    Network : Cluster Network 2
    State   : Up

    Name    : MBX-3 - REPL-B
    Node    : MBX-3
    Network : Cluster Network 3
    State   : Up

    Name    : MBX-4 - REPL-B
    Node    : MBX-4
    Network : Cluster Network 3
    State   : Failed

    Name    : MBX-3 - LAN-B
    Node    : MBX-3
    Network : Cluster Network 4
    State   : Up

    Name    : MBX-4 - LAN-B
    Node    : MBX-4
    Network : Cluster Network 4
    State   : Up

    image

     

    The copy status for the databases hosted on MBX-4 is healthy.

     

    [PS] C:\>Get-MailboxDatabaseCopyStatus *

    Name                                          Status          CopyQueue ReplayQueue LastInspectedLogTime   ContentIndex
                                                                  Length    Length                             State
    ----                                          ------          --------- ----------- --------------------   ------------
    DAG-DB0\MBX-1                                 Mounted         0         0                                  Healthy
    DAG-DB0\MBX-2                                 Healthy         0         0           4/29/2014 2:11:47 PM   Healthy
    DAG-DB0\MBX-3                                 Healthy         0         0           4/29/2014 2:11:47 PM   Healthy
    DAG-DB0\MBX-4                                 Healthy         0         0           4/29/2014 2:11:47 PM   Healthy

     

    When reviewing the connection status for the databases on MBX-4, we see that the Replication service is using the MAPI network for log shipping.  Servers that have no issues with the Replication interface continue to use that interface.

     

    [PS] C:\>Get-MailboxDatabaseCopyStatus * -ConnectionStatus | fl name,incominglogcopyingnetwork,outgoingconnections

    Name                      : DAG-DB0\MBX-1
    IncomingLogCopyingNetwork :
    OutgoingConnections       : {}

    Name                      : DAG-DB0\MBX-2
    IncomingLogCopyingNetwork : {MBX-1,ReplicationDagNetwork01}
    OutgoingConnections       :

    Name                      : DAG-DB0\MBX-3
    IncomingLogCopyingNetwork : {MBX-1,ReplicationDagNetwork01}
    OutgoingConnections       :

    Name                      : DAG-DB0\MBX-4
    IncomingLogCopyingNetwork : {MBX-1,MapiDagNetwork}
    OutgoingConnections       :

     

    When the interface was marked as failed, the Replication service successfully failed over to the MAPI network.

     

    But what happens if the interface is not FAILED, but the interface configuration is invalid?   In this event, the Cluster service cannot pass cluster traffic between these two interfaces and the associated network is marked as partitioned.

     

    [PS] C:\>Get-ClusterNetwork | fl

    Name  : Cluster Network 1
    State : Up

    Name  : Cluster Network 2
    State : Up

    Name  : Cluster Network 3
    State : Partitioned

    Name  : Cluster Network 4
    State : Up

    image

     

    The interfaces within the partitioned network are marked as unreachable.

     

    [PS] C:\>Get-ClusterNetworkInterface | fl

    Name    : MBX-1 - LAN-A
    Node    : MBX-1
    Network : Cluster Network 1
    State   : Up

    Name    : MBX-2 - LAN-A
    Node    : MBX-2
    Network : Cluster Network 1
    State   : Up

    Name    : MBX-1 - REPL-A
    Node    : MBX-1
    Network : Cluster Network 2
    State   : Up

    Name    : MBX-2 - REPL-A
    Node    : MBX-2
    Network : Cluster Network 2
    State   : Up

    Name    : MBX-3 - REPL-B
    Node    : MBX-3
    Network : Cluster Network 3
    State   : Unreachable

    Name    : MBX-4 - REPL-B
    Node    : MBX-4
    Network : Cluster Network 3
    State   : Unreachable

    Name    : MBX-3 - LAN-B
    Node    : MBX-3
    Network : Cluster Network 4
    State   : Up

    Name    : MBX-4 - LAN-B
    Node    : MBX-4
    Network : Cluster Network 4
    State   : Up

     

    image

     

    What happens to the copies that are hosted on the servers with an unreachable interface status?

     

    [PS] C:\>Get-MailboxDatabaseCopyStatus * | fl name,status

    Name   : DAG-DB0\MBX-1
    Status : Mounted

    Name   : DAG-DB0\MBX-2
    Status : Healthy

    Name   : DAG-DB0\MBX-3
    Status : DisconnectedAndHealthy

    Name   : DAG-DB0\MBX-4
    Status : DisconnectedAndHealthy

     

    An unreachable interface is not the same as a failed interface.  This resulted in the databases entering a disconnected state and replication not failing over to the MAPI network.  The connection status confirms this failure.

     

    [PS] C:\>Get-MailboxDatabaseCopyStatus * -ConnectionStatus | fl name,incominglogcopyingnetwork,outgoingconnections

    Name                      : DAG-DB0\MBX-1
    IncomingLogCopyingNetwork :
    OutgoingConnections       : {}

    Name                      : DAG-DB0\MBX-2
    IncomingLogCopyingNetwork : {MBX-1,ReplicationDagNetwork01}
    OutgoingConnections       :

    Name                      : DAG-DB0\MBX-3
    IncomingLogCopyingNetwork : {MBX-1,,A timeout occurred while communicating with server 'MBX-1'. Error: "A connection
                                could not be completed within 15 seconds."}
    OutgoingConnections       :

    Name                      : DAG-DB0\MBX-4
    IncomingLogCopyingNetwork : {MBX-1,,A timeout occurred while communicating with server 'MBX-1'. Error: "A connection
                                could not be completed within 15 seconds."}
    OutgoingConnections       :

     

    The network failure detection mechanism is the same in both Exchange 2010 and Exchange 2013, as well as the same in Windows 2008 R2, Windows 2012, and Windows 2012 R2 failover clusters.  In order for the Replication service to detect a failure of a Replication network, the operating system and Cluster service must report the underlying interface as failed.  If the Cluster service reports any other status for the interface, the Replication service will consider the network to be valid and replication will not failover to another network.

  • Office 365: More options button missing when configuring migration batch

    In Office 365 mailboxes are migrated to the service by configuring a migration batch.  When establishing the move configuration settings a “More Options” button was present.  The “More Options” button allowed administrators to configure the bad item limit and large item limit when the migration batch is created.

     

    image

     

    In current versions of the Office 365 / Exchange management tools the “More Options” button is missing.

     

    image

     

    The “More Options” button was removed as a part of the Office 365 / Exchange Management tools upgrade. 

     

    If the bad item limit and large item limit must be adjusted, they must now be adjusted after the migration batch has been created.  These settings can only be adjusted on a migration batch that is not in progress. 

     

    When creating new migration batches where these settings should be modified administrators should select the option “Manually start the batch later (by selecting it in the migration dashboard and then clicking Start)”.  This will stage the migration batch but not start it, allowing administrators to immediately adjust the bad item and large item limits.  The status of the migration batch will be “created”.

     

    image

     

    If the migration batch was created and has started it must be stopped.  This can be performed by selecting the migration batch and pressing the stop button (square button).  This will place the migration batch into a “stopped” state.

     

    image

     

    With the migration batch created or stopped the properties of the batch can be accessed by selecting the batch and pressing the edit button (pencil button).  On the properties of the batch, on the general tab, the bad item limit and large item limit are editable. 

     

    image

     

    After entering the appropriate values the save button can be utilized to commit the changes to the batch.  The batch can then be started or resumed by selecting the batch and pressing the resume button (play button). 

     

    At this time we expect the “More Options” button to appear in the Office 365 / Exchange management tools in a future version. 

  • Office 365: Why do my distribution group names change?

    I recently worked with a customer that was utilizing directory synchronization to create distribution groups in their on-premises active directory and have them mail enabled within Office 365.  They noticed that when creating these distribution groups the display name in Office 365 was automatically changed and differed from the display name set on-premises.

     

    Let’s take a look…

     

    Using Active Directory Users and Computers a new distribution list is created.

     

    image

     

    Using the attribute editor the following attributes were manually set:

     

    DisplayName:  TestDL

    ProxyAddresses:  SMTP:TestDL@domain.com

    Mail:  TestDL@Domain.com

     

    After the distribution list was created directory synchronization was performed.  Monitoring directory synchronization we can validate the properties of the group synchronized into Office 365.

     

    image

     

    Using Powershell connected to Office 365 we can validate the properties of the MSOL Group.

     

    PS C:\Users\timmcmic> Get-MsolGroup -ObjectId df617972-c874-4d6d-ba73-993e73219514 | fl

    ExtensionData    : System.Runtime.Serialization.ExtensionDataObject
    CommonName       : TestDL
    Description      :
    DisplayName      : TestDL
    EmailAddress     : TestDL@domain.com

    Errors           : {}
    GroupType        : DistributionList
    IsSystem         : False
    LastDirSyncTime  : 4/9/2014 2:56:34 PM
    ManagedBy        :
    ObjectId         : df617972-c874-4d6d-ba73-993e73219514
    ProxyAddresses   : {smtp:TestDL@domain.onmicrosoft.com, SMTP:TestDL@domain.com}
    ValidationStatus : Healthy

     

    The attributes of the group within Office 365 and the on-premises Active Directory match after directory synchronization has completed.

     

    When reviewing the properties of the same distribution list from Office 365 Exchange it is noted that the name has changed.  In this case a prefix was appended DL_:

     

    PS C:\Users\timmcmic> Get-DistributionGroup TestDL | fl NAME,DISPLAYNAME,EMAILADDRESSES

    Name           : DL_TestDL
    DisplayName    : DL_TestDL
    EmailAddresses : {SMTP:TestDL@domain.com, smtp:TestDL@domain.onmicrosoft.com}

    Where did the DL_ come from?  Exchange and Office 365 allow administrators to define a distribution group naming policy.  The distribution group naming policy is set in the organization’s configuration.  More information on distribution group naming policies can be found here:  http://aka.ms/Bry5y2

     

    In this instance the tenant had a distribution group naming policy that utilized DL_<GroupName>:

     

    PS C:\Users\timmcmic> Get-OrganizationConfig | fl distributiongroupnamingpolicy

    DistributionGroupNamingPolicy : DL_<GroupName>

     

    When a distribution group naming policy is utilized after directory synchronization has successfully synchronized the group and the new group is provisioned within Exchange Office 365 the naming policy will be applied.  The MSOL object will continue to reflect the attributes as synchronized from the on-premises Active Directory but the Exchange object will reflect the attributes modified by the naming policy.

     

    In our case it was desired that the naming policy would not be applied.  This required removing the naming policy from the organizational configuration:

     

    PS C:\Users\timmcmic> Set-OrganizationConfig -DistributionGroupNamingPolicy:$NULL

     

    By removing the naming policy the Exchange Office 365 groups will now reflect the attributes as synchronized from the on-premises Active Directory.