Let us assume you have the problem that permissions assigned to a mailbox are somehow “lost”. The settings of the security descriptor property on the mailbox in the information store and the Active Directory (AD) attribute msExchMailboxSecurityDescriptor do not match after some time. Please refer to the Microsoft Knowledge Base article 310866 for a description of the attribute msExchMailboxSecurityDescriptor. So far, you do not know the root cause and you only found out that assigning full access permission to the special user account “NT Authority\Self” is a workaround for this issue. For a short time-period, the permission settings are in sync again. However, do not forget Outlook auto-mapping or you will run into the issue described in this article.

Auto-Mapping is using the AD attribute msExchDelegateListLink and msExchDelegateListBL. As you can see in the previous screenshot these attributes are empty.

MFCMAPI shows that you have a connection to the Public Folder store and to your mailbox. Now you execute the “workaround”: Add-MailboxPermission –Identity <MailboxID> -AccessRights FullAccess -User "NT AUTHORITY\SELF"

The screenshot shows that the attributes used for auto-mapping now contain the distinguished name of the mailbox. The auto-mapping feature points back to the same mailbox. This causes the following issue.

AutoDiscover will tell Outlook that it should also open the same mailbox as Alternative Mailbox. You will see the mailbox twice in Outlook. Once with the primary SMTP address and once with the display name.

MFCMAPI shows that you now have multiple connections to the same mailbox – Test1@Fabrikam.local and Test1.

This issue does not occur if you use the parameter AutoMapping $False as described in this TechNet article.

Sometimes companies do not want that a user is aware that his mailbox is put on hold, and they do not want that users are able to see which other mailboxes are on hold.

By default, this is not the case. An Exchange administrator can use the following two commands to list all mailboxes in the Exchange organization that are on litigation hold or included in an in-place hold.

Get-mailbox -Filter { LitigationHoldEnabled -eq $true } | fl name, LitigationHold*, InPlace*

Get-Mailbox | Where-Object { $_.InplaceHolds -ne $null } | fl name, LitigationHold*, InPlace*

A user can use Remote PowerShell to check whether his mailbox is on hold.

Get-mailbox | fl name, LitigationHold*, InPlace*

Exchange Server 2010 litigation hold and the “legacy” litigation hold in Exchange Server 2013 are using the AD user attributes msExchLitigationHoldDate and msExchLitigationHoldOwner to store information about litigation hold.

Exchange Server 2013 in-place hold is using the AD user attribute msExchUserHoldPolicies.

Default security in AD allows authenticated users read access to all attributes. This enables a user to use a LDAP browser to search for users in AD with a mailbox put on hold. Therefore, a user is not only able to verify whether his mailbox is on hold, he is also able to find other users with a mailbox on hold. One of my customer rated this as a security breach.

I am going to investigate whether it is possible to hide this information and if this would be a supported configuration.

You can find many articles on the Internet about the Recoverable Items folder and Single Item Recovery, for example, “Single Item Recovery in Exchange Server 2010”.

However, you might not be aware of the following issue until you are challenged with a corresponding help desk call. Let’s assume a user has the following folder structure in his inbox.

Now the user decides to delete the complete TopLevel folder. If the user only performs a regular delete then the folder is moved to the Deleted Items folder.

If the user now again deletes the folder or has configured “Empty Deleted Items folder when existing Outlook”, or maybe was so careless and performed a Shift Delete then the folder hierarchy is gone.

You might think no problem. I can use the Recover Deleted Items wizard and everything will be restored again –of course using the same folder hierarchy without any information loss.

Surprise, you have no luck!

The folder structure is lost, and you are challenged with a flat list including all the mails that you have deleted previously regardless in which folder they were initially located. You have to pick the correct emails from a list with several hundred items. This depends on the configured deleted item retention period of the database hosting your mailbox.

There are no subfolders beneath the Deletions folder and the individual items in this folder currently do not preserve their initial folder path.

I hope that in a future Exchange version the folder hierarchy will be preserved. This should enable the user to recover the complete folder structure including all corresponding emails.

I will give a webcast for the WindowsITPro magazine on May 28.

Learning Role Based Access Control with Real Life Examples

You can read a lot of articles on the Internet about Role Based Access Control (RBAC) in Exchange Server. However, RBAC is a difficult topic and it is likely that you still have trouble using RBAC. In this session we will explain the RBAC components and use examples from customer projects to facilitate your learning experience. You will hear how you can use management scopes to restrict recipient administrators to manage only objects located in a specific Active Directory Organizational Unit (OU). We discuss how you can use exclusive scopes to prevent regular administrators from modifying Exchange attributes of your VIP users. You will learn topics such as using a custom management role assignment policy to control which users can or cannot use the Exchange Control Panel (ECP) to manage their distribution group membership or update their contact details.

You can use this link to register for the webcast.

Last week I was asked to help a colleague with a PowerShell script. The requirement was to write the primary SMTP address of all internal Exchange recipients to a file. The interesting part was that the file has to be written with the UNIX file format. A UNIX mail program will use the file to import it in its person based routing table.

I used the VIM editor to check the file format. Initially I tried the following two methods.

Get-Recipient -Filter { RecipientType -ne "MailContact" -and RecipientType -ne "MailUser"} | % { $_.PrimarySmtpAddress } | Out-File -FilePath D:\temp\File1.txt -Encoding UTF8

Get-Recipient -Filter { RecipientType -ne "MailContact" -and RecipientType -ne "MailUser"} | % { $_.PrimarySmtpAddress } | Set-Content -Path D:\temp\File2.txt -Encoding UTF8

Finally I used:

Get-Recipient -Filter { RecipientType -ne "MailContact" -and RecipientType -ne "MailUser"} | % -Begin { $str ="" } { $str += $_.PrimarySmtpAddress.ToString() + "`n" } -End {[System.IO.File]::WriteAllText("D:\temp\File3.txt",$str,[System.Text.Encoding]::UTF8)}

In the previous post "Restricting the Scope of a eDiscovery Search Using a Recipient Restriction Filter" I described the issue that you currently cannot use a custom attribute to restrict the scope of an eDiscovery search.

In the meantime I received the information that this issue will very likely not get fixed. The proposed workaround is to add users to groups and check group membership in the recipient restriction filter.

The following example shows how you can setup such a configuration.

The important part is the definition of the management scope:

New-ManagementScope -Name Scope-US-Mailboxes -RecipientRoot Fabrikam.local/Customer -RecipientRestrictionFilter { MemberOfGroup -eq "CN=DL-US-Mailboxes,OU=Customer,DC=Fabrikam,DC=local" }

The Microsoft TechNet article “Understanding Mailbox Audit Logging” contains the following section:

By using mailbox audit logging, you can log mailbox access by mailbox owners, administrators, and delegates (including administrators who have full mailbox access permissions). Mailboxes are considered to be accessed by an administrator only in the following scenarios:

• Discovery search is used to search a mailbox
• The New-MailboxExportRequest cmdlet is used to export a mailbox
• Microsoft Exchange Server MAPI Editor is used to access the mailbox

Recently I investigated how we can audit the actions performed by a software program that used Exchange Web Services to access a mailbox. I was especially interested in how actions are logged if the software is “Using Exchange Impersonation”. I found out the above list is incomplete. Actions performed using impersonation are recorded with Logon Type Admin.

If you use ExFolders to access a mailbox then this is logged with Logon Type Admin, too.

The Microsoft TechNet article Understanding Recoverable Items says: “To better meet customers’ legal compliance requirements, the dumpster is reinvented as the Recoverable Items folder in Exchange 2010. The Recoverable Items folder resides in the non-IPM subtree of each mailbox. The non-IPM subtree is a storage area within the mailbox that contains operational data about the mailbox. This subtree isn’t visible to users using Outlook, Microsoft Office Outlook Web App, or other e-mail clients.”

Is it possible for a user to access to this areas? Yes, but not with a regular email client.

An end user, who is not an Exchange administrator and has only access to his own mailbox, can use MFCMAPI to investigate the content in this “hidden” area of his mailbox. If his MAPI profile is configured for Cached Exchange Mode then he has to enable the Online Mode in MFCMAPI, otherwise MFCMAPI accesses the OST file and the Recoverable Items Folder is not visible.

Now MFCMAPI accesses the Exchange Server and you can browse through the folders of your mailbox.

The following screenshot shows the content in the DiscoveryHolds subfolder of a mailbox hosted on Exchange Server 2013.

Another option for an end user is to use the EWSEditor.

Both tools provide interesting features including the option to export an email to a file or delete an item in the mailbox. However, the delete function does not allow a user to purge an email from his mailbox. So far I haven’t found a loophole how a user can hide a discriminating email from a discovery search.

I am currently working with a customer that is migrating about 180 000 Lotus Notes mailboxes to Exchange Server 2010. The Exchange Server environment is a private cloud provided by an external company. The mailboxes belong to employees from all over the world. Compliance is an important topic of the project. We have to technically ensure that a legal officer of a certain country, for example US, is only able to perform eDiscovery tasks with mailboxes belonging to US employees.

The AD OU structure is fixed. The customer is not allowed to change the AD structure of the resource forest hosting the Exchange environment. All mailboxes of the environment are beneath a single OU. Only contacts or distribution groups are located in another OU. The proposed solution was to use CustomAttribute9 to store a value that identifies the business unit / country of the corresponding employee.

However, we encountered a bug related to recipient restriction filters and multi-mailbox search / in-place eDiscovery that is currently existing in Exchange Server 2010 and Exchange Server 2013.

You can create the RBAC configuration and execute the New-MailboxSearch cmdlet without any issue. When the search is performed by Exchange in the background an error occurs that leads to the following error message: “Property ‘CustomAttribute9’ is not present on object ‘UserA’.”

The following picture shows the configuration steps including how to use a recipient restriction filter to define a management scope.

The next screenshot are the commands used by the legal officer to execute the mailbox search.

As long as the bug is not fixed you will encounter the following error.

I faced the following error when I tried to create my first Hyper-V VM on my new laptop.

I used the Resultant Set of Policy MMC and checked the User Rights Assignment configuration. I found that somebody has linked a Group Policy Object (GPO) to the domain container that assigns several domain user accounts the Logon as Service right. This is a very bad idea. You should not manually modify the Default Domain Policy or link a GPO with User Rights Assignments to the top hierarchy of the domain.

During the installation of Hyper-V the Local Group Policy Object (LGPO) was automatically modified, but the settings of the domain GPO is processed afterwards and overwrites the values of the LGPO. We used security filtering to block this domain GPO from my laptop. Afterwards the User Rights Assignments of the LGPO was active again. Now I can create VMs without any problems.

You can read additional information about the NT VIRTUAL MACHINE\Virtual Machines security group that was introduced with Hyper-V on Windows Server 2012 / Windows 8 in the blog article “Logon Failures Involving Virtual Machines in Windows Server 2012”. A similar problem is described in the Microsoft knowledge base article “Starting or Live Migrating Hyper-V virtual machines may fail with error 0x80070569 on Windows Server 2012-based computers”.