Archive for March, 2017

Prevent archiving of Calendar and TASK in Exchange 2010 SP3

March 29, 2017 No comments

Calendar and Tasks retention tags are only controlled via the administrator.

Users cannot assign different retention tags to either the Calendar or Tasks folders or calendar and task items.

Two important implications of using Retention Policies to manage messages after Exchange 2010 SP2 RU4.

  1. Beginning with Exchange 2010 SP2 RU4, administrators can create retention tags via the cmdline for use with the Calendar and Tasks default folders. The supported retention actions are: DeleteAndAllowRecovery, PermanentlyDelete, MarkAsPastRetentionLimit.  Note that calendar and task items can be moved to the archive mailbox via the MoveToArchive retention action that is associated with the All or Personal retention tag type.
  2. Default Policy Tags (DPTs) used to move or delete items will now apply to Calendar and Tasks folders.

Because the retention actions MoveToDeletedItems and MoveToArchive are not supported for calendar and task type, we cannot use command to prevent default delete DPT from applying to calendar and task default folder. To work around this issue, we can disable this functionality by adding the following registry key to Mailbox servers:

Path: HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeMailboxAssistants\Parameters

Name: ELCAssistantCalendarTaskRetentionEnabled


Value: 0 = Do not process Calendar and Task folders

Value: 1 = Process (default )

Or place the mailbox in a retention hold.

i.      Non-recurring tasks:

1.      A non-recurring task expires (or moves to the archive) according to its message-received date, if one exists.

2.      If a non-recurring task does not have a message-received date, it expires (or moves to the archive) according to its message-creation date.

3.      If a non-recurring task has neither a message-received date nor a message-creation date, it neither expires nor gets moved to the archive.

ii.     Recurring tasks expire (or move to the archive) according to the end date of last occurrence. If a recurring task doesn’t have an end date, it does not expire (and isn’t moved to the archive).

iii.    A regenerating task (which is a recurring task that regenerates a specified time after the preceding instance of the task is completed) doesn’t expire (or get moved to the archive).

iv.     If an item is found within the Tasks folder that doesn’t have a proper item type, it’s ignored (as the item might be corrupt).




Categories: Uncategorized Tags:

Exchange 2010 Database copy on server has content index catalog files in the following state: Failed

March 21, 2017 No comments

Exchange 2010 Database copy on server has content index catalog files in the following state: Failed

• Restarting Microsoft Search Service 

Get-MailboxDatabaseCopyStatus –Server [Server]| fl Name,*Index*

ContentIndexState : failed
ContentIndexErrorMessage : Catalog needs a reset for database {GUID}

Reseed Purposes

• GetMailboxDatabaseCopyStatus * | where {$_.ContentIndexState eq “Failed”}
• GetMailboxDatabaseCopyStatus * | where {$_.ContentIndexStateeq “Failed”| UpdateMailboxDatabaseCopy CatalogOnly

Do you need to suspend the database copy first before running update-mailboxdatabasecopy?
• Not if you’re just fixing failed content indexes.
Categories: Uncategorized Tags:


March 13, 2017 No comments

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the latest email authentication standard in addition to SPF (Sender Policy Framework) and DKIM (Domain Keys Identified Mail). 

What it is: DMARC authenticates against established DKIM and SPF standards, and ensures fraudulent activity from domains under a organization’s control (active sending domains, non-sending domains, and defensively registered domains) is blocked. Two key values of DMARC are domain alignment and reporting.

How it works: DMARC’s alignment feature prevents spoofing of the “header from” address by:

  1. Matches “header from” with the “envelope from” used during an SPF check, and
  2. Matches “header from” with the “d= domain name” in the DKIM signature.

Passing DMARC: A message must pass SPF authentication and SPF alignment and/or DKIM authentication and DKIM alignment. A message will fail DMARC if the message fails both (1) SPF or SPF alignment and (2) DKIM or DKIM alignment.

DMARC policy instructs how messages are handled if DMARC fails, removing any guesswork

  • Setup Monitoring (Audit) to identify the behavior and e-mails failing DMARC
  • Quarantine messages that fail DMARC, OR
  • Reject messages that fail DMARC

Why it matters: DMARC is the latest and first widely deployed email authentication standard that can make the “header from” address reliable. Ultimately, it discourages bad actors to go after a brand with a DMARC record.

Categories: Uncategorized Tags:

RISK of Allowing automatically forwarding

Outlook allows users to set up rules to auto-forward emails to any valid SMTP email address. Allowing auto-forwarding to external reciepents compromises the protection of sensitive information including intellectual property. While it is convenience to have all your e-mails in one place – Forwarding company e-mail for example to a personal webmail account is huge security risk and increases the potential for data leakage. 


• Convenience is compromising security

• Hard to track who has auto-forwarding setup 



Categories: Uncategorized Tags: