User Profile
surajbudhani
MicrosoftJoined 5 years ago
User Widgets
Recent Discussions
Users cannot see [External] tag in OWA and Outlook Conversation View
There are multiple ways to add [External] tag to emails received from outside the organization. O365 users can use the Native [External] tag in Office 365. You can apply [External] tag using transport rule in Exchange and Office 365. You can also set up [External] tag using rules in your third-party gateway. Exchange Team has already covered the first two options in their blog Native external sender callouts on email in Outlook. In this post I just wanted to talk about an intermittent issue where [External] tags behave differently for different emails. For example, You have 2 emails with [External] tag in the subject. When you reply to the first email you see the tag replaced with RE: and when you reply to the second email the tag is appended with RE: [EXTERNAL]. When you enable conversation view in Outlook or OWA you don’t see the [External] tag in the message preview for some emails, while it still shows for some other emails. But when you double click on either of the two emails the tag can be seen in the Subject line. The underlying cause for the issue lies in the MAPI properties of the email and the mechanism used to add the tag. There is one major difference between the Conversation View and Normal View. In normal view, the message preview displays the value in the MAPI property PR_SUBJECT. However, when we see the email in conversation view the message preview displays another MAPI property “PR_CONVERSATION_TOPIC” and that’s why in most cases you will not see the external tag. You can check these properties using MFC MAPI. In OWA, Conversation View is set by default, and you won’t see External tag in the message preview. You can click on Settings and change the view. A message store provider has the option of assuring that “PR_CONVERSATION_TOPIC” property is always set on incoming or outgoing messages. If these properties are already set, they should not be altered. If not, they can be set to PR_NORMALIZED_SUBJECT. So “PR_CONVERSATION_TOPIC” gets the value from “PR_NORMALIZED_SUBJECT” Now let’s find why is the value in “PR_NORMALIZED_SUBJECT” and PR_SUBJECT different? First Scenario: If the PR_SUBJECT_PREFIX is present and is an initial substring of PR_SUBJECT. In that case PR_NORMALIZED_SUBJECT and associated properties are set to the contents of PR_SUBJECT with the prefix removed. For First Scenario it is straight forward, as the PR_SUBJECT_PREFIX property was set explicitly, the string can be of any length and use any alphanumeric characters, but it must match a substring at the beginning of the PR_SUBJECT property. Here “External” will be removed from Subject when setting the value for “PR_NORMALIZED_SUBJECT” PR_SUBJECT_PREFIX is External: PR_SUBJECT is External: This is an Important Email PR_NORMALIZED_SUBJECT is This is an Important Email PR_CONVERSATION_TOPIC is This is an Important Email If this is the case with an email, it will not display External tag in message preview and when you reply to this email it will change the tag from External: to Re: Second Scenario: If the PR_SUBJECT_PREFIX is present, but it is not an initial substring of PR_SUBJECT, PR_SUBJECT_PREFIX is deleted and recalculated from PR_SUBJECT. Third Scenario: If PR_SUBJECT_PREFIX is not present, it is calculated from PR_SUBJECT In Second and Third Scenario, the property PR_SUBJECT_PREFIX is not set or needs to be recalculated. The rule for computing the prefix is that PR_SUBJECT must begin with one, two, or three letters (alphabetic only) followed by a colon and a space. If such a substring is found at the beginning of PR_SUBJECT, it is then added to PR_SUBJECT_PREFIX. Otherwise, PR_SUBJECT_PREFIX property remains unset. By design if store must calculate or recalculate the value of PR_SUBJECT_PREFIX then it will fail to calculate [External] as it is more than 3 alphabets long. This means PR_SUBJECT_PREFIX property will remain unset PR_SUBJECT_PREFIX is PR_SUBJECT is External: This is an Important Email PR_NORMALIZED_SUBJECT is External: This is an Important Email PR_CONVERSATION_TOPIC is External: This is an Important Email If this is the case with an email, it will display External tag in message preview because it is now the subject itself and when you reply to this email it will change the tag from External: to RE: [EXTERNAL]. Now that you understand when and why will you experience this problem you can circle back to tagging rule to fix this. You can check the protocol logs to find why the two emails were processed differently. This can happen either due to conflicting rule or if the tagging rule modifies Thread-Topic and Subject headers differently.Re: Duplicate emails on two domains (.com and .co.uk)
You can either use email address policy to add secondary email address to all the users. Or you can just run one PowerShell command to update the secondary email address. $AllMailbox = Get-Mailbox -ResultSize Unlimited Foreach($A in $AllMailbox){ $NewEmail = $A.Alias + "@domain.co.uk" Set-Mailbox $A.Alias -EmailAddresses @{Add=$NewEmail}} If the alias is john and email address is "john @ domain.com". This will add an additional SMTP as "john @ domain2.co.uk"Re: Add Exchange 2016 to existing Exchange 2010 DAG
No Daniel, that's not how DAG works. You cannot add Exchange 2016 Servers to Exchange 2010 DAG. All the servers in a DAG should be of the same Version. Hence, due to obvious reasons you cannot add a Database Copy of Exchange 2010 Mailbox database on Exchange 2016. If you want to move mailboxes from 2010 to 2016 you will have to migrate them.Re: Merge mailboxes on two exchange on premise servers
Assuming you are trying to build a Dev environment for testing purpose. You can use Exchange DSC to get the details of the existing environment and deploy a new server with similar configuration. https://github.com/dsccommunity/xExchange But when it comes to merging mailboxes, you can't merge mailboxes, you will have to create new mailboxes and if its a small environment and you want these mailboxes to have data. Get it using pst (If it is for testing). It will help if you can elaborate on what you are referring to as "Mailbox Merging"Re: Unable to receive email on Office 365 through Barracuda
Can you check and confirm if this issue is with just a specific set of users or multiple users. If its is with a specific set of users. Try sending a test email and check if internal emails work just fine. If Internal emails don't work check the email address and proxy address attributes. If the issue is only with External emails in that case DBEB could possibly be blocking the emails. Try setting up the type of accepted domain from Authoritative to Internal Relay and test sending the emails and see if you get similar error.
