Errors when launching EMS after (re)deployment

After installing Exchange 2010 SP1 on all of the nodes in an environment, I was told that we were going to go with a different design, installing onto a different drive. The uninstall, and subsequent re-install to the other drive completed, and the installation went smoothly.  Everything seemed to be in order with Exchange...when using EMC.  When I launch EMS, however, I received the following error:

VERBOSE: Connecting to server.domain.com
[server.domain.com] Connecting to remote server failed with the following error message : The connection to the specified remote host was refused. Verify that the WS-Management service is running on the remote host and configured to listen for requests on the correct port and HTTP URL. For more information, see the about_Remote_Troubleshooting Help topic
.
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportException
    + FullyQualifiedErrorId : PSSessionOpenFailed
VERBOSE: Connecting to server.domain.com

I looked around for a bit and checked all of the normal things..

WinRM installed, configured and listening..check.

Powershell application pool started (and recycled)..check.

Validate Exchange-specific paths set to D:\ rather than C:\ in IIS...check.

Validate the kerbauth.dll is Local/Native to the PowerShell virtual directory, etc.. check.

Validated my account has remote PS rights..check.

At this point it definitely seemed to be either an IIS issue, or an authentication issue.  The fix turned out to be one of the values in "C:\Windows\System32\Inetsrv\config\ApplicationHost.config," specifically:

<globalModules>
     <add name="kerbauth" image="C:\Program Files\Microsoft\Exchange Server\V14\Bin\kerbauth.dll">

As you can see, this value is set to C:\ rather than D:\.  Evidently uninstalling Exchange, and reinstalling it didn't change this value.  Upon changing this value, EMS suddenly started working, and all was well.

We chose to go through and uninstall Exchange, as well as IIS, and redeploy regardless to be on the safe side.  It seemed to be a small amount of work given that the systems were still pre-pilot, and there could potentially be more files that had not been updated.  This approach works just as well, though it is obviously more time consuming.

Mailbox Auditing Explained

What is mailbox audit logging?

Mailbox audit logging is used for tracking logons to a specific mailbox as well as actions and changes that are made during the session.  It can also be used to track ‘Send As,’ ‘SendOnBehalfOf,’  creations, deletions, etc.

This logging can generate many logs which can consume a good amount of space, and is thus disabled by default.

Enabling mailbox audit logging on a mailbox

Example cmdlet to enable:

Set-Mailbox -Identity "JoshTest" -AuditEnabled $true

In order to perform mailbox audit logging, you need to be a member of a role group with the “Audit Logs” role assigned to it.  Two default role groups that have this functionality are:

• Organization Management
• Records Management

You can create custom role groups as well; reference the ‘RBAC Explained’ article.

Enabling auditing will automatically include administrator and delegate actions by default, while omitting actions made by the mailbox owner.

Searching mailbox audit logs

There are three ways to search mailbox audit logs: Synchronous, Asynchronous, GUI (via ECP).

Example Type: 

Synchronous.

Task Description:                            

Perform a synchronous mailbox audit log search with the goal of finding all audit log entries for JoshTest’s mailbox regarding admin/delegate actions in the time frame of 2/20/2011 – 2/25/2011, and display the results in the powershell window.

Cmdlet Example:        

    

Search-MailboxAuditLog -Identity JoshTest -LogonTypes Admin,Delegate -StartDate 2/20/2011 -EndDate 2/25/2011

Full Syntax Considerations:       

http://technet.microsoft.com/en-us/library/ff522360.aspx

Example Type:                 

Asynchronous.

Task:                                    

Perform an asynchronous mailbox audit log search with the goal of finding all audit log entries for JoshTest's mailbox regarding delegate actions in the time frame of 2/20/2011 – 2/25/2011, and populate an XML file with the results to be delivered via e-mail upon completion.

Cmdlet Example:                            

New-MailboxAuditLogSearch "Delegate Actions on JoshTest" -Mailboxes "JoshTest" -LogonTypes Delegate -StartDate 3/1/2011 –EndDate 3/1/2011 -StatusMailRecipients Mailbox.Auditor@azaleos.com

Full Syntax Considerations:       

http://technet.microsoft.com/en-us/library/ff522362.aspx

Example Type:                 

GUI / ECP

Task:                    

Perform a mailbox audit log search via the ECP with the goal of finding all audit log entries for a user regarding administrative actions on 3/1/2011, and populate an XML file with the results to be delivered via e-mail upon completion.

Steps:

Log in as an admin account (see prior requirements) to the ECP, or to OWA and enter the ECP via the Options section.

Navigate to ‘Roles and Auditing’ and then ‘Auditing.’

Export mailbox audit logs:

Fill out the criteria for the user to search, the scope, and who to send the report to:

In time, you will receive the output in XML format at the e-mail address specified:

Full Considerations:      

http://help.outlook.com/en-us/beta/37618aac-bd50-4322-9054-502461690ed9.aspx?sl=1

Interpreting the mailbox audit log

Example:

MailboxGuid="1a5348dc-2bdd-4606-9d22-59005ca2eb7c" 

Owner="AVictim" 

LastAccessed="2011-03-01T22:42:41.0772536-07:00" 

Operation="SendAs"

ItemId="RgAAAADH7DJI8nRmW9d7HDLIvGH+JsErT8IbDiflR6zCD/BEMJIcAAAA4j5cAABaE7PuVtsyT6zCD/BEMJIcAAAA4pUbAAAJ" 

ItemSubject="You're fired!" 

OperationResult="Succeeded" 

LogonType="Delegate" 

ClientInfoString="Client=OWA" 

ClientIPAddress="10.10.15.15" 

InternalLogonType="Owner" 

MailboxOwnerUPN="AVictim@raymond.com" 

MailboxOwnerSid="S-1-5-21-1542865472-92671928-526660263-5723"

LogonUserDisplayName="A. Badman" 

LogonUserSid="S-1-5-21-1542865472-92671928-526660263-3722"

OriginatingServer="EXCHANGE01 (14.01.0218.011)"

MailboxGuid="1a5348dc-2bdd-4606-9d22-59005ca2eb7c" 

Owner=" AVictim" 

LastAccessed="2011-03-01T22:42:41.061631-07:00"

Operation="Create" 

ItemId="RgAAAADH7DJI8nRmW9d7HDLIvGH+JsErT8IbDiflR6zCD/BEMJIcAAAA4j5cAABaE7PuVtsyT6zCD/BEMJIcAAAA4pUbAAAJ" 

ItemSubject="You're fired!" 

OperationResult="Succeeded" 

LogonType="Delegate" 

FolderId="LgAAAABN9DVF1dUmR6o4DOZQiD9+AQBaE7PuVtsyT6zCD/BEMJIcAAAA4j5cAAAB" FolderPathName="\Drafts" 

ClientInfoString="Client=OWA" 

ClientIPAddress="10.10.15.15" 

InternalLogonType="Owner" 

MailboxOwnerUPN=" AVictim@raymond.com" 

MailboxOwnerSid="S-1-5-21-1542865472-92671928-526660263-5723" 

LogonUserDisplayName="A. Badman" 

LogonUserSid="S-1-5-21-1542865472-92671928-526660263-3722" 

OriginatingServer="EXCHANGE01 (14.01.0218.011)

Judging by this output, it looks like A. Badman has logged on successfully, created the original draft, and sent an e-mail as (Send As) A. Victim via OWA at 22:42:41 on 3/1/2011.  It also looks like the e-mail wasn’t work appropriate with a subject like that!
 

MailboxGuid="1a5348dc-2bdd-4606-9d22-59005ca2eb7c" 

Owner=" AVictim"

LastAccessed="2011-03-01T23:18:51.2507346-07:00" 

Operation="HardDelete" 

OperationResult="Succeeded" 

LogonType="Delegate" 

FolderId="LgAAAABN9DVF1dUmR6o4DOZQiD9+AQBaE7PuVtsyT6zCD/BEMJIcAAAA4j5RAAAB" 

FolderPathName="\Inbox" 

ClientInfoString="Client=MSExchangeRPC" 

ClientIPAddress="10.10.15.15" 

ClientProcessName="OUTLOOK.EXE" 

ClientVersion="12.0.6550.5000" 

InternalLogonType="Owner" 

MailboxOwnerUPN="AVictim@raymond.com" 

MailboxOwnerSid="S-1-5-21-1542865472-92671928-526660263-5723" 

CrossMailboxOperation="false" 

LogonUserDisplayName="A. Badman" 

LogonUserSid="S-1-5-21-1542865472-92671928-526660263-3722" 

OriginatingServer="EXCHANGE01 (14.01.0218.011)"

It would also appear that A. Badman has been busy deleting items from the mailbox as well.  You can see from the log that this was done via Outlook 2007.

A quick-hit list of the important fields:

Field	Description
Owner	The owner of the mailbox that was accessed by a non-owner.
LastAccessed	The date and time when the mailbox was accessed.
Operation	The action that was performed by the non-owner. For more information, see the " What gets logged in the mailbox audit log?" section in Run a Non-Owner Mailbox Access Report
OperationResult	Whether the action performed by the non-owner succeeded or failed.
LogonType	The type of non-owner access. These include administrator, delegate, and external.
FolderPathName	The name of the folder that contained the message that was affected by the non-owner.
ClientInfoString	Information about the mail client used by the non-owner to access the mailbox.
ClientIPAddress	The IP address of the computer used by the non-owner to access the mailbox.
InternalLogonType	The logon type of the account used by the non-owner to access this mailbox.
MailboxOwnerUPN	The e-mail address of the mailbox owner.
LogonUserDN	The display name of the non-owner.
Subject	The subject line of the e-mail message that was affected by the non-owner.

Table originally pulled from outlook help link located here.

The full field list is here:

http://technet.microsoft.com/en-us/library/ff459237.aspx#Mailbox

RBAC Explained

RBAC is a newer technology with Exchange 2010 that seems to have a lot of IT professionals scratching their heads; especially when it comes to the terminology. First off, what is RBAC?

Role Based Access Control (RBAC) is a new permission model introduced in Exchange 2010. In the past, manually changing ACLs could cause collateral damage, and often times had longer reaching implications. For this reason, Microsoft opted to go with a model where administrators could easily allocate permissions via default or custom Role Groups. Now let’s try to decipher what this means in a way that is easier to understand.

Role Group: A Role Group is essentially a special Universal Security Group (USG) that has members and Roles assigned to it. You can actually see these in ADUC. These Role Groups are essentially used like any other kind of group; they are for standard permission allocation to a subset of users.

Predefined Role Group Example:

Discovery Management Role – Grants the ability to perform multi-mailbox search, and compliance exports. Encompasses the Legal Hold and Mailbox Search Roles.

Assigning a user to a Role Group:

Add-RoleGroupMember -Identity "Discovery Management" -Member

Role: A Role is basically a predefined list of Role Entities packaged up, and ready to assign to a Role Group (or directly to a user, though it is generally better to create a Custom Role Group if one does not currently exist that meets the need). By default, Exchange 2010 has 65 built-in roles.

Administrators can create child roles as well. These roles are limited by their parents by what rights they can have. Child roles cannot have more roles than the parent.

Predefined Role Example:

Mailbox Search – Contains the following permissions:

Mailbox Search	Get-ADServerSettings
Mailbox Search	Get-DomainController
Mailbox Search	Get-Mailbox
Mailbox Search	Get-MailboxExportRequest
Mailbox Search	Get-MailboxExportRequestStatistics
Mailbox Search	Get-MailboxSearch
Mailbox Search	Get-Recipient
Mailbox Search	New-MailboxExportRequest
Mailbox Search	New-MailboxSearch
Mailbox Search	Remove-MailboxExportRequest
Mailbox Search	Remove-MailboxSearch
Mailbox Search	Search-Mailbox
Mailbox Search	Set-ADServerSettings
Mailbox Search	Set-MailboxExportRequest
Mailbox Search	Set-MailboxSearch
Mailbox Search	Start-MailboxSearch
Mailbox Search	Stop-MailboxSearch
Mailbox Search	Suspend-MailboxExportRequest
Mailbox Search	Write-AdminAuditLog

To output the list of Role Entries assigned to the “Mailbox Search” role, you would run:

Get-ManagementRoleEntry "Mailbox Search\*”

Assigning a Role to a Role Group:

New-ManagementRoleAssignment -SecurityGroup -Role

Role Scope: A Role Scope is essentially the scope of the rights provided to the user receiving the permissions. All Roles have a default Role Scope, so if you don’t set one, then it will be provided with the defaults. You can also create custom scopes to quickly apply to Roles when necessary.

Example of a scope:

New-ManagementScope -name "Tier 3 Technicians" -RecipientRestrictionFilter {memberofgroup -eq "cn=Executives,ou=Exec,dc=domain,dc=com"}

Role Entries: These are the tools that Roles have access to in their toolbox, limited of course by scope.

Example: Get-User and other cmdlets

Role Assignment: This is the tricky one. A Role Assignment is essentially an object that links together a Role, a Role Group, and a Role Scope into one package. Anytime you apply a Role with a Scope to a Role Group (yes even if they are defaults), you are creating a Role Assignment.

Given how many different combinations you can have, Exchange comes with around 160 Role Assignments by default according to the Exchange team!

Role Delegates: A delegate is someone who can assign the role to users/groups/etc, but they don't necessarily have the role themselves. The most common application of this is that the Organization Management role tends to have delegate rights to most roles, which means they can assign roles to users or groups, while not having the permission themselves. The auditing for this comes in at the Admin Audit Log level.

Example:

The Discovery Management role can be assigned by the Organization Management role, but members of only the Organization Management role do not have the discovery functionality by default that those belonging to the Discovery Management role have.

Conclusion

The bottom line is that people learn in different ways. If this article didn’t help you, then the EHLO blog’s explanation very good as well, but with a slightly different style that may compliment your learning style.

One thing they mention is labeling them in a way that is familiar to us:

Who: Role Group

What: Role

Where: Scope

Glue (holds it all together) : Role Assignment

For the triangle of power explanation, visit the EHLO blog:

http://msexchangeteam.com/archive/2009/11/16/453222.aspx