virtual study beta exam 71-663 exchange 2010 designing and deploying messaging compliance system...

Microsoft Exchange 2010 - 71-633: Pro: Designing and Deploying Messaging

Solutions with Microsoft Exchange Server 2010

Designing and Deploying Messaging Compliance, System Monitoring, and Reporting

Tobiasz Janusz Koprowskiaka Anorak

Kilka słów o mnie

• związany z informatyką od połowy lat dziewięddziesiątych• kilkuletnie doświadczenie w informatyce bankowej *Zorba, AS/400, ICBS, BTeller+• od ponad czterech lat pracuje w Centrum Przetwarzania Danych• na co dzieo zajmujący się MOSS, Disaster Recovery, High Availibility, wirtualizacją, bezpieczeostwem fizycznym, tworzeniem procedur bezpieczeostwa, umowami SLA, ISO• konsultant i wdrożeniowiec przy projektach audytów licencyjnych, systemów procedur bezpieczeostwa i operacyjnych, tworzenia ośrodków przetwarzania danych, wdrożeniach platformy Microsoft Office SharePoint, Avocent, Rittal• Corporate Microsoft Gold Partner Program Administrator, Volume Licensing Administrator• uczestnik kilku programów Microsoft: Connect, Community Leadership Programm, ITPro Momentum, VS2010 Terminology Community, Windows 7 Beta 2 PL, Desktop Deployment Planning Service, New Efficiency Program• lider wrocławskiej grupy PLSSUG• prelegent na spotkaniach społeczności•Microsoft System Center Influencer• Członek Technical Support Team w GITCA (wcześniej Culminis) odpowiedzialny za rejon EMEA, APAC, NORAM, LATAM• autor kilku artykułów technicznych i recenzent wydawnictwa aPress• właściciel kilku blogów (w tym dwóch specjalizowanych)

2009-12-18 VirtualStudy.pl 2


This objective may include but is not limited to: audit logging;admin audit logging; permissions auditing; message tracking;protocol logging; RBAC (compliance role and scope); identifyrequirements for discovery or auditing; plan journaling ormessage record management (MRM) for discovery; plan accesspermissions for discovery searches

Design and deploy auditing and discovery.

Administrator Audit LoggingYou can use administrator audit logging in Microsoft Exchange Server 2010 to logwhen a user or administrator in your organization runs a cmdlet. By keeping a log ofthe cmdlets that are run, you can trace changes to the person who made the change,augment your change logs with detailed records of the change as it was implemented,comply with regulatory requirements and requests for discovery, and more.

What Gets Audited

• Cmdlets that are run directly in the Exchange Management Shell are audited. In addition, operations performed using the Exchange Management Console (EMC) and the Exchange Web management interface are also logged because those operations run cmdlets in the background.

• Cmdlets, regardless of where they are run, will be audited if a cmdlet is on the cmdlet auditing list and one or more parameters on that cmdlet are on the parameter auditing list. Get cmdlets aren't logged. Audit logging is intended to show what actions have been taken to modify objects in an Exchange organization rather than what objects have been viewed.



Administrator Audit LoggingBy default, if audit logging is enabled, a log entry is created every time any cmdlet, other than a Get cmdlet, isrun. When you configure audit logging, you need to specify the mailbox where you want logs to be stored. Ifyou don't want to audit every cmdlet that's run, you can configure audit logging to audit only the cmdlets andparameters you're interested in. You configure audit logging with the Set-AdminAuditLogConfig cmdlet. Theparameters referenced in the following sections are used with this cmdlet.



Field Description

Message Subject Account of the user who ran the cmdlet and the cmdlet that was run.

Cmdlet Name Cmdlet run by the caller.

Object Modified Object modified by the cmdlet.

Parameter Parameters specified when the cmdlet was run and the values provided. If more than one parameter was specified, multiple Parameter fields are shown.

Caller User account of the user who ran the cmdlet.

Succeeded Whether the cmdlet ran successfully. The value is either True or False.

Error Error message generated if the cmdlet failed to complete successfully.

Run Date Date and time when the cmdlet was run. The date and time are stored in Coordinated Universal Time (UTC) format.

Administrator Audit Logging - cmdlets

Specify the cmdlets to be audited By default, audit logging creates a log entry for every cmdlet that's run. If you're enabling auditlogging for the first time and want this behavior, you don't have to change the cmdlet audit list. Ifyou've previously specified cmdlets to audit and now want to audit all cmdlets, you can audit allcmdlets by specifying the wildcard character ( * ) with the AdminAuditLogCmdlets parameter onthe Set-AdminAuditLogConfig cmdlet as shown in the following command:

Set-AdminAuditLogConfig -AdminAuditLogCmdlets *

You can specify which cmdlets to audit by providing a list of cmdlets using theAdminAuditLogCmdlets parameter. When you provide the list of cmdlets to audit, you canprovide single cmdlets, cmdlets with wildcard characters ( * ), or a mix of both. Each entry in thelist is separated by commas. The following values are all valid: *New-Mailbox | *TransportRule |*Management | *Set-Transport*

For example, the following command audits the cmdlets specified in the list above:

Set-AdminAuditLogConfig -AdminAuditLogCmdlets New-Mailbox, *TransportRule,*Management, Set-Transport*




Specify the parameters to be audited By default, audit logging creates a log entry for every cmdlet that's run, regardless of theparameters that are specified. If you're enabling audit logging for the first time and want thisbehavior, you don't have to change the parameter audit list. If you've previously specifiedparameters to audit and now want to audit all parameters, you can do so by specifying thewildcard character ( * ) with the AdminAuditLogParameters parameter on the Set-AdminAuditLogConfig cmdlet as shown in the following command:

Set-AdminAuditLogConfig -AdminAuditLogParameters *

You can specify which parameters you want to audit by using the AdminAuditLogParametersparameter. When you provide the list of parameters to audit, you can provide single parameters,parameters with wildcard characters ( * ), or a mix of both. Each entry in the list is separated bycommas. The following values are all valid: *Database | *Address | *Custom | *Region

For example, the following command audits the parameters specified in the list above:

Set-AdminAuditLogConfig -AdminAuditLogParameters Database, *Address*, Custom*, *Region




Specify the auditing mailbox You can specify the SMTP address of the mailbox where you want to store administrator auditlogs using the AdminAuditLogMailbox parameter on the Set-AdminAuditLogConfig cmdlet. TheSMTP address should be a mailbox that resides within your Exchange organization. For example,to store the audit logs in the mailbox with the SMTP address [email protected], use thefollowing command:

Set-AdminAuditLogConfig -AdminAuditLogMailbox [email protected]

Enable administrator audit logging You need to be assigned permissions before you can perform this procedure. To see whatpermissions you need, see the "Administrator audit logging" entry in the Exchange and ShellInfrastructure Permissions topic.

If you haven't previously configured administrator audit logging, you must specify the cmdletsand parameters to be audited and specify an auditing mailbox before you enable administratoraudit logging. You can enable administrator audit logging by setting the AdminAuditLogEnabledparameter to $True on the Set-AdminAuditLogConfig cmdlet. For example, run the followingcommand to enable administrator audit logging:

Set-AdminAuditLogConfig -AdminAuditLogEnabled $True ||( $False)



RBAC – Role Based Access ControlRole Based Access Control (RBAC) is the new permissions model in Microsoft Exchange Server 2010. With RBAC, you don't need to modify and manage access control lists (ACLs), which was done in Exchange Server 2007. ACLs created several challenges in Exchange 2007, such as modifying ACLs without causing unintended consequences, maintaining ACL modifications through upgrades, and troubleshooting problems that occurred due to using ACLs in a nonstandard way.

• RBAC enables you to control, at both broad and granular levels, what administrators and end-users can do. RBAC also enables you to more closely align the roles you assign users and administrators to the actual roles they hold within your organization. In Exchange 2007, the server permissions model applied only to the administrators who managed the Exchange 2007 infrastructure. In Exchange 2010, RBAC now controls both the administrative tasks that can be performed and the extent to which users can now administer their own mailbox and distribution groups.

• RBAC has two primary ways of assigning permissions to users in your organization, depending on whether the user is an administrator or specialist user, or an end-user: management role groups and management role assignment policies. Each method associates users with the permissions they need to perform their jobs. A third, more advanced method, direct user role assignment, can also be used.



RBAC – Role Based Access Control (ITPro)

• Management role group The management role group is a special universal security group (USG) thatcontains mailboxes, users, USGs, and other role groups that are members of the role group. This is whereyou add and remove members, and it's also what management roles are assigned to. The combination ofall the roles on a role group defines everything that users added to a role group can manage in theExchange organization.

• Management role A management role is a container for a grouping of management role entries. Rolesare used to define the specific tasks that can be performed by the members of a role group that's assignedthe role. A management role entry is a cmdlet, script, or special permission that enables each specific taskin a role to be performed.

• Management role assignment A management role assignment links a role and a role group. Assigning arole to a role group grants members of the role group the ability to use the cmdlets and parametersdefined in the role. Role assignments can use management scopes to control where the assignment can beused.

• Management role scope A management role scope is the scope of influence or impact on a roleassignment. When a role is assigned with a scope to a role group, the management scope targetsspecifically what objects that assignment is allowed to manage. The assignment, and its scope, are thengiven to the members of the role group, and restrict what those members can manage. A scope canconsist of servers, organizational units (OUs), or filters on server or recipient objects..



Management Role Groups

RBAC – Role Based Access Control (EndUser)

Role assignment policies consist of the following components that define what users can do with their ownmailboxes. Notice that some of the same components also apply to role groups. When used with roleassignment policies, these components are limited to enable users to manage only their own mailbox:

• Management role assignment policy The management role assignment policy is a special object inExchange 2010. Users are associated with the role assignment policy when their mailboxes are created orif you change the role assignment policy on a mailbox. This is also what you assign end-user managementroles to. The combination of all the roles on a role assignment policy defines everything that the user canmanage on his or her mailbox or distribution groups.

• Management role A management role is a container for a grouping of management role entries. Rolesare used to define the specific tasks that a user can do with his or her mailbox or distribution groups. Amanagement role entry is a cmdlet, script or special permission that enables each specific task in amanagement role to be performed. You can only use end-user roles with role assignment policies.

• Management role assignment A management role assignment is the link between a role and a roleassignment policy. Assigning a role to a role assignment policy grants the ability to use the cmdlets andparameters defined in the role. When you create a role assignment between a role assignment policy anda role, you can't specify any scope. The scope applied by the assignment is either Self or MyGAL. All roleassignments are scoped to the user's mailbox or distribution groups.



Management Role Assignment Policies

RBAC – Role Based Access Control (short version 1)

Role groups:

• One or more administrators can be members of a role group. They can also be members of more than one role group.

• The role group is assigned one or more role assignments. These link the role group with one or more administrative roles that define what tasks can be performed.

• The role assignments can contain management scopes that define where the users of the role group can perform actions. The scopes determine where the users of the role group can modify configuration.

Role assignment policies:

• One or more users can be associated with a role assignment policy.

• The role assignment policy is assigned one or more role assignments. These link the role assignment policy with one or more end-user roles. The end-user roles define what the user can configure on his or her mailbox.

• The role assignments between role assignment policies and roles have built-in scopes that restrict the scope of assignments to the user's own mailbox or distribution groups.

Direct role assignment (advanced):

• A role assignment can be created directly between a user or USG and one or more roles. The role defines what tasks the user or USG can perform.

• The role assignments can contain management scopes that define where the user or USG can perform actions. The scopes determine where the user or USG can modify configuration.



RBAC – Role Based Access Control (short version 2)



The Three UC Amigos (Supporting US Education):http://blogs.technet.com/ucedsg/archive/2009/05/26/exchange-2010-management-tools.aspx

Access permissions for discovery searches

Multi-Mailbox Search can be a useful search and data collection tool for different audienceswithin organizations, and serve different needs. The following are some common uses of Multi-Mailbox Search:

• Legal discovery Complying with legal discovery requests for messaging records isincreasingly becoming one of the most important tasks for organizations involved in lawsuits.Without a dedicated tool, searching messaging records spread over a number of differentmailboxes, which reside in different mailbox databases on e-mail servers throughout adispersed organization, can be a time-consuming and resource-intensive task. Whenreceiving requests for messaging records pertaining to a certain subject, Multi-MailboxSearch can search a large volume of e-mail messages stored in mailboxes across one or moreExchange 2010 servers, and possibly in different locations.

• Internal investigations Requests from managers or legal departments as part of internalinvestigations can be handled by Multi-Mailbox Search.

• Human Resources monitoring Requests from HR departments as part of regular monitoringof e-mail content or specific searches based on HR requirements can be handled by Multi-Mailbox Search.



Access permissions for discovery searches



The following applies to performing a discovery search:• Keywords • Senders and recipients • Date range • Mailboxes • Personal archive• Attachments • Unsearchable Items • Safe list • IRM-protected items

Note: Multi-Mailbox Search doesn't support regular expressions.

Access permissions for discovery searches (viewing, logging)



Viewing Search Results

Search results are copied to the discovery mailbox selected as the target mailbox for the search. If you use a discovery mailboxother than the default Discovery Search Mailbox as the target mailbox, you must assign mailbox access permissions to authorizedusers to allow them to access that discovery mailbox. Authorized users with mailbox access permissions can access the mailboxusing Outlook Web App or Outlook.

A new folder bearing the same name as the search is created in the target mailbox. A subfolder is created for each mailboxsearched to store messages returned from that mailbox. The mailbox user's display name along with the date and time of searchcreation is used for the folder name. Messages are copied to a folder with the same name as their location in the searchedmailbox. For example, if the search name is Discovery-ProjectContoso, and a message located in the Inbox folder in Paul Shen'sprimary mailbox is returned, the folder hierarchy created in the discovery mailbox would be Discovery-ProjectContoso -> PaulShen-9/4/2009 3:57:10 PM -> Primary Mailbox > Inbox. Any message flags, including read/unread status and follow-up flags, aremaintained.

Logging of Discovery Searches

There are two types of logging available for discovery searches:

• Basic logging Basic logging is enabled by default for all mailbox searches. It includes information about the search and whoperformed it. Information captured about basic logging appears in the body of the e-mail message sent to the mailboxwhere the search results are stored. This message is located in the folder created to store search results.

• Full logging Full logging includes information about all messages returned by the search. This information is provided in acomma-separated value (CSV) file attached to the e-mail message that contains basic logging information. The name of thesearch is used for the CSV file name. This information may be required for compliance or record-keeping purposes. To enablefull logging, you must select Enable full logging in the EMC, or specify the logging level using the LoggingLevel parameter inthe Shell.

Access permissions for discovery searches (shell)



Use the Shell to add a user to the Discovery Management role group

Note: You can't use the EMC to add a user to the Discovery Management role group. This example adds theuser EAdams to the Discovery Management role group.

Add-RoleGroupMember –Identity "Discovery Management" -Member Eadams

Use the Shell to create a discovery search

This example creates the discovery search Contoso-Case1. The search will return e-mail messages that meetthe following conditions: Contain the words Contoso and Project A | Sent or received from January 1, 2009,through December 31, 2009. The search is run against all mailboxes within all Exchange 2010 Mailbox serversin the organization. Search results will be saved in the mailbox Discovery Search Mailbox, in a folder with thesame name as the search. Full logging is enabled for the search.

New-MailboxSearch -Name "Contoso-Case1" -StartDate "1/1/2009" -EndDate "12/31/2009" -TargetMailbox"Discovery Search Mailbox" -SearchQuery '"Contoso" and "Project A"'-MessageTypes Email -IncludeUnsearchableItems -LogLevel Full

###

Stop|Start-MailboxSearch -Name "Discovery-ProjectContoso„

Set-MailboxSearch -Identity "Search-Project Contoso" -SourceMailboxes "DG-ProjectManagers„

Remove-MailboxSearch "Discovery-ProjectContoso„

New-Mailbox SearchResults -Discovery -UserPrincipalName [email protected]

Get-Mailbox -Resultsize unlimited -Filter {RecipientTypeDetails -eq "DiscoveryMailbox"}

Set-Mailbox [email protected] -LitigationHoldEnabled $true | $false

mailto:[email protected]




This objective may include but is not limited to: dumpster 2.0;legal hold; retention policies (MRM); retention tags; long-termbackup; design and deploy managed folders; design and deployalternate mailboxes; plan for managing messages in defaultOutlook folders; plan for managing messages in custommanaged folders; plan a retention policy implementation; planan AutoTagging implementation

Design and deploy message archival.

Dumpster 2.0The Dumpster. In Exchange 2010 we introduce the new Dumpster 2.0. This is a completely different Dumpster than what we’ve had in the past.

An end user can do a soft delete or a hard delete on a message. The soft delete is when the item has been deleted from the deleted items folder – this item is placed in the dumpster. The hard delete is when an item has been marked for purge out of the store. There is also a hard delete via Outlook when a user uses Shift-Delete and this places the item directly in the dumpster bypassing the deleted items folder.

To help reduce the burden for the administrator most of my customers change the default from 14 days to 30 days and provide guidance for users to check the deleted items folder to recover mail vs. going to tape to recover an email.



Messaging Records Management

Messaging records management (MRM) is the records management technology in Microsoft Exchange Server 2010 that helps organizations reduce the legal risks associated with e-mail. MRM makes it easier to keep the messages needed to comply with company policy, government regulations, or legal needs, and to remove content that has no legal or business value. This is accomplished through the use of retention policies or managed folders:

• Retention policies Retention policies, the new MRM technology in Exchange 2010, use retention tags to apply retention settings. You create retention tags, and link them to a retention policy. Mailboxes that have a retention policy applied to them are processed by the managed folder assistant, a mailbox assistant that runs on a schedule and provisions retention tags in mailboxes.

• Managed folders Managed folders, the MRM technology introduced in Exchange Server 2007 and also available in Exchange 2010, have managed content settings applied to them. You create managed folders and link them to a managed folder mailbox policy. Mailboxes that have managed folder mailbox policies applied to them are processed by the managed folder assistant, a mailbox assistant that runs on a schedule and provisions managed folders in mailboxes.

When a message reaches its retention age, the retention action specified in the retention tag (or the managed content settings for a managed folder) is taken. Messages can be moved to the Deleted Items folder, deleted with the ability to recover them from the Recoverable Items folder, or permanently deleted.



MRM – Retention Policies (obrazkowo)



MRM – Retention Policies The retention settings that you can specify include a message class, whether retention is enabled for the specified message class, the retention age, and a retention action. The retention age specifies the period for which a message is retained in the mailbox. The retention action specifies the action to take after the item is past its retention age. For example, you can create a managed content setting for a managed default folder, such as Inbox, to expire items of all message classes after 120 days, and select the Move to Deleted Items folder action. You can also create additional managed content settings for the same folder to specify different retention settings for calendar items.

You can select from one of the following retention actions:

• Move to the deleted items folder Use this action to move items to the Deleted Items folder upon expiration.Move to a managed custom folder Use this action to move items to a managed custom folder. You must create the managed custom folder before you can select it using this action.

• Delete and Allow Recovery Use this action to move items to the recoverable items folder. Deleted items are available for recovery from the recoverable items folder until the deleted item retention time specified for the mailbox store or the mailbox user elapses.

• Permanently Delete Use this action to permanently delete items. Permanently deleted items can't be recovered by users.

• Mark as Past Retention Limit Use this action to mark items as expired after they reach their retention age. Items marked as expired are displayed using strikethrough text in Microsoft Outlook 2010 and Office Outlook 2007.

For calendar items and recurring tasks, the retention age is calculated from the end date of the item



Messaging Records Management

Subjects:

• Applies to: Exchange Server 2010 Topic Last Modified: 2009-12-07

• Understanding Messaging Records Management Learn more about Messaging Records Management (MRM).

• Understanding Retention Policies Learn more about retention policies, the new MRM feature in Exchange 2010.

• Understanding Managed Folders Learn more about managed folders, the MRM feature introduced in Exchange 2007 and also available in Exchange 2010.

• Planning for Messaging Records Management Learn more about the factors you should consider when planning to deploy MRM in your organization.

• How Retention Age is Calculated Learn how the retention age is calculated for different types of mailbox items, such as e-mail messages, calendar items, and tasks.

• Deploying Messaging Records Management Learn how to deploy MRM in your Exchange 2010 organization.

• Monitoring Messaging Records Management Learn about the tools available to monitor MRM, including MRM-related performance counters.

• Messaging Records Management Terminology in Exchange 2010 Learn more about the terminology used for MRM in Exchange 2010.



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


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


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




AutoTaggingUse the Set-MailboxComplianceConfiguration cmdlet to enable AutoTagging for a mailbox. Before enabling AutoTagging for a mailbox, the mailbox user must have tagged at least 500 messages using either item-level or folder-level tags. Syntax:

Set-MailboxComplianceConfiguration -Identity <MailboxIdParameter> [-Confirm [<SwitchParameter>]] [-DomainController <Fqdn>] [-IgnoreDefaultScope <SwitchParameter>] [-RetentionAutoTaggingEnabled <$true | $false>] [-WhatIf [<SwitchParameter>]]

Use the Get-MailboxComplianceConfiguration cmdlet to get the AutoTagging status of a mailbox. Syntax:

Get-MailboxComplianceConfiguration [-Identity <MailboxIdParameter>] [-Credential <PSCredential>] [-DomainController <Fqdn>] [-Filter <String>] [-IgnoreDefaultScope <SwitchParameter>] [-Organization <OrganizationIdParameter>] [-OrganizationalUnit <OrganizationalUnitIdParameter>] [-ReadFromDomainController <SwitchParameter>] [-ResultSize <Unlimited>] [-SortBy <String>]

Get-MailboxComplianceConfiguration [-Anr <String>] [-Credential <PSCredential>] [-DomainController <Fqdn>] [-Filter <String>] [-IgnoreDefaultScope <SwitchParameter>] [-Organization <OrganizationIdParameter>] [-OrganizationalUnit <OrganizationalUnitIdParameter>] [-ReadFromDomainController <SwitchParameter>] [-ResultSize <Unlimited>] [-SortBy <String>]

DODATKOWY OPIS DO POLECENIA GET: http://technet.microsoft.com/en-us/library/dd298061.aspx







AutoTagging



Parameter Required Type Description

Identity RequiredMicrosoft.Exchange.Configuration.Tasks.MailboxIdParameter

The Identity parameter specifies the mailbox. You can use one of the following values:GUIDDistinguishedName (DN)Domain\Account User principal name (UPN)LegacyExchangeDNSmtpAddressAlias

Confirm OptionalSystem.Management.Automation.SwitchParameter

The Confirm switch causes the command to pause processing and requires you to acknowledge what the command will do before processing continues. You don't have to specify a value with the Confirm switch.

DomainController

OptionalMicrosoft.Exchange.Data.Fqdn

The DomainController parameter specifies the fully qualified domain name (FQDN) of the domain controller that writes this configuration change to Active Directory.

IgnoreDefaultScope

OptionalSystem.Management.Automation.SwitchParameter

The IgnoreDefaultScope parameter isn't available in this release.

RetentionAutoTaggingEnabled

Optional System.Boolean

The RetentionAutoTaggingEnabled parameter specifies whether to enable retention AutoTagging.You can use one of the following values:•$true This value enables AutoTagging.•$false This value disables AutoTagging.

WhatIf OptionalSystem.Management.Automation.SwitchParameter

The WhatIf switch instructs the command to simulate the actions that it would take on the object. By using the WhatIf switch, you can view what changes would occur without having to apply any of those changes. You don't have to specify a value with the WhatIf switch.


This objective may include but is not limited to: RMS; ethicalfirewall; message journaling; disclaimers; mail tips, such asnotification for external recipients and recipient limits

Design and deploy transport rules for message compliance



LESS RESTRICTIVE MORE RESTRICTIVE

• Apply the right level of control based on the sensitivity of the data

• Maximize control and minimize unnecessary user disruptions

Alert “Allow delivery

but add a warning.”

Append “Allow delivery

but add a disclaimer.”

Protect“Allow delivery

but prevent forwarding.”

Redirect“Block delivery and redirect.”

Review “Block delivery until reviewed.”

Block“Do not deliver.”

Modify “Allow delivery

but modify message.”

Classify “Allow delivery

but apply classification.”



Alert users about potential risks




Transport Rules

• Executed on the Hub Transport Server

• Structured like Inbox rules

• Apply to all messages sent inside and outside the organization

• Configured with simple GUI in Exchange Management Console

Easily enforce granular policies



Specific Users Detects mail between people, distribution lists

Specific Content Inspects subject, header and body for keywords, regular expressions

Message Properties Inspect message headers and properties or type

Classifications Scans for classifications such as Attorney-Client Privileged

Attachments Scans size, name and content (Office documents)

Classifications Can now also act on No Classifications

Message Types IRM protected, auto-replies, calendaring, voice mail

Supervision Lists Allows/Blocks based on listed recipients

Management Properties Identifies manager and applies policy

User Properties Scans for user attributes (such as department, country)

Fine tune rules with detailed criteriaConditions



Actions

Block Blocks and deletes message and can send non-delivery report

Classify Applies classification such as attorney-client privilege

Modify Adds disclaimer to body or text to subject line

Reroute Adds additional recipients to cc or Bcc line or re-directs

Append Applies disclaimer per each user’s specific attributes

Review Enables review and approval of e-mail before delivery

Protect Applies rights protection to messages, attachments

Apply the appropriate level of control



• Persistent protection – Protects your sensitive information no matter where it is sent

– Usage rights locked within the document itself

– Protects online and offline, inside and outside of the firewall

• Granular control – Users apply IRM protection directly within an e-mail

– Organizations can create custom usage policy templates such as "Confidential—Read Only"

– Limit file access to only authorized users

Information Rights Management (IRM) provides persistent protection to control who can access, forward, print, or copy sensitive data within an e-mail.

Granular protection that travels with the data



Transport Protection Rules

IRM protection can be triggered based on sender, recipient, content and other conditions | Office 2003, 2007, and 2010 attachments also protected

Apply RMS policies automatically using Transport Rules

Apply “Do Not Forward” or custom RMS templates

Automatically apply IRM



Outlook Protection RulesProvide users more IRM protection options

IRM protection can still be applied manually

User can be granted option to turn off rule for non-sensitive e-mail

Adding recipient or distribution list can trigger IRM protection automatically before sending



IRM in Outlook Web App

Native support for IRM in OWA eliminates need for Internet Explorer Rights Management add-on

Office documents also protected

Access to standard and custom RMS templates

Read and reply to protected messages



Protected Voice Mail

“Do Not Forward” template

Prevent forwarding of voice mail

• Integration with AD RMS and Exchange Unified Messaging

• Permissions designated by sender (by marking the message as private) or by administrative policy



Protected messages sent to transport server

Messages and attachments decrypted to enable content filtering, transport rules

Infected messages and spam can be filtered

Messages are re-encrypted and delivered

IRM Decryption Enable scanning, filtering, journaling

Journaled messages include decrypted clear-text copy



Protection and Control Scenarios

Ethical WallRestrict e-mail between analysts and brokers

• Transport rules to block mail between specific users or groups

Supervision Manager required to sign-off on mail to sensitive partner

• Send to manager for approval• MailTips for moderated recipients

HR Policy Inappropriate content • Filter for keywords and block, redirect, modify

Privacy

HIPAA (health data) GLBA (financial data) PIPEDA (Canada) PCI (Worldwide)

• Apply MailTips to alerts for external recipients• Apply IRM protection to control access• Monitor for credit card numbers and other

personally identifiable information (PII)

Signatures EUPD 2003/58/EC• Append disclaimer that includes name, title,

department, etc.



Automatically monitor and control the distribution of sensitive information

Better protect access to data with persistent Information Rights Management

Ensure the right level of control is applied to the right messages

IPC with Exchange Server 2010


This objective may include but is not limited to: design anddeploy message flow monitoring; client accessibility; SLArequirements, such as percent of email delivered in a certainamount of time within the organization; analyze message usage,number of messages, and message size; analysis and design ofongoing infrastructure improvements due to increased capacity,performance, and requested features; monitoring client accessservices; troubleshooting client access services

Design and deploy for monitoring and reporting.

Message Flow Monitoring

Use the Test-Mailflow cmdlet to diagnose whether mail can be successfully sent from and delivered to the system mailbox on acomputer that has the Mailbox server role installed. You can also use this cmdlet to verify that e-mail is sent between Mailboxservers within a defined latency threshold. Syntax:

Test-Mailflow [-Identity <ServerIdParameter>] [-ActiveDirectoryTimeout <Int32>] [-Confirm [<SwitchParameter>]] [-DomainController <Fqdn>] [-ErrorLatency <Int32>] [-ExecutionTimeout <Int32>] [-MonitoringContext <$true | $false>] [-WhatIf[<SwitchParameter>]]

Test-Mailflow [-Identity <ServerIdParameter>] -TargetDatabase <DatabaseIdParameter> [-ActiveDirectoryTimeout <Int32>] [-Confirm [<SwitchParameter>]] [-DomainController <Fqdn>] [-ErrorLatency <Int32>] [-ExecutionTimeout <Int32>] [-MonitoringContext <$true | $false>] [-WhatIf [<SwitchParameter>]]

Test-Mailflow [-Identity <ServerIdParameter>] -TargetEmailAddress <String> [-ActiveDirectoryTimeout <Int32>] [-Confirm[<SwitchParameter>]] [-DomainController <Fqdn>] [-ErrorLatency <Int32>] [-ExecutionTimeout <Int32>] [-MonitoringContext<$true | $false>] [-TargetEmailAddressDisplayName <String>] [-WhatIf [<SwitchParameter>]]

Test-Mailflow [-Identity <ServerIdParameter>] -TargetMailboxServer <ServerIdParameter> [-ActiveDirectoryTimeout <Int32>] [-Confirm [<SwitchParameter>]] [-DomainController <Fqdn>] [-ErrorLatency <Int32>] [-ExecutionTimeout <Int32>] [-MonitoringContext <$true | $false>] [-WhatIf [<SwitchParameter>]]

Test-Mailflow [-Identity <ServerIdParameter>] -AutoDiscoverTargetMailboxServer <SwitchParameter> [-ActiveDirectoryTimeout <Int32>] [-Confirm [<SwitchParameter>]] [-DomainController <Fqdn>] [-ErrorLatency <Int32>] [-ExecutionTimeout <Int32>] [-MonitoringContext <$true | $false>] [-WhatIf [<SwitchParameter>]]



Message Flow MonitoringParameter Required Type Description

AutoDiscoverTargetMailboxServer

RequiredSystem.Management.Automation.SwitchParameter

The AutoDiscoverTargetMailboxServer parameter specifies whether to automatically populate a list of target Mailbox servers to which to send a test message. The task queries Active Directory to discover all Mailbox servers and then sends each server a test message.

TargetDatabase RequiredMicrosoft.Exchange.Configuration.Tasks.DatabaseIdParameter

The TargetDatabase parameter specifies the mailbox database to which test messages are sent.

TargetEmailAddress Required System.StringThe TargetEmailAddress parameter specifies the SMTP address of the mailbox to which test messages are sent. Use this parameter to send test messages to a Mailbox server in a remote forest. If this parameter is used, the test is always a remote test.

TargetMailboxServer RequiredMicrosoft.Exchange.Configuration.Tasks.ServerIdParameter

The TargetMailboxServer parameter specifies one or more Mailbox servers in the local Exchange organization to which test messages are sent.

ActiveDirectoryTimeout

Optional System.Int32The ActiveDirectoryTimeout parameter specifies the number of seconds that elapse before the task provides an informational message about the delay. The default value is 15 seconds.

Confirm OptionalSystem.Management.Automation.SwitchParameter

The Confirm switch causes the command to pause processing and requires you to acknowledge what the command will do before processing continues. You don't have to specify a value with the Confirm switch.

DomainController OptionalMicrosoft.Exchange.Data.Fqdn

The DomainController parameter specifies the fully qualified domain name (FQDN) of the domain controller that retrieves data from Active Directory.



Message Flow MonitoringParameter Required Type Description

ErrorLatency Optional System.Int32

The ErrorLatency parameter specifies how long to wait for a test message to be delivered before an error event is logged in Microsoft System Center Operations Manager 2007. The default value when a test message is sent to the local Mailbox server is 15 seconds and 180 seconds when a test message is sent to a remote Mailbox server.

ExecutionTimeout Optional System.Int32

The ExecutionTimeout parameter specifies the maximum time that this task can run before the test is determined to be a failure. If no test message or delivery report arrives before this time expires, the task ends and an error is reported. When the task is run in the Exchange Management Shell, the default setting is 240 seconds. When the MonitoringContext parameter is used, the default setting is 15 seconds.

Identity OptionalMicrosoft.Exchange.Configuration.Tasks.ServerIdParameter

The Identity parameter specifies the source Mailbox server name or source mailbox SMTP address from which a test message is sent. The default value is the local Mailbox server.

MonitoringContext Optional System.Boolean

The MonitoringContext parameter is used only when System Center Operations Manager 2007 is being used for server monitoring. If you set the value to $true, the command populates the MonitoringContext object with events and performance counters used by System Center Operations Manager 2007. The default value of this parameter is $false.

TargetEmailAddressDisplayName

Optional System.StringThe TargetEmailAddressDisplayName parameter specifies the display name of the mailbox to which test messages are sent.

WhatIf OptionalSystem.Management.Automation.SwitchParameter

The WhatIf switch instructs the command to simulate the actions that it would take on the object. By using the WhatIf switch, you can view what changes would occur without having to apply any of those changes. You don't have to specify a value with the WhatIf switch.



SLA – Service Level Agreement (1)

• There are two major parts to an SLA: the governing document and theprocess.

• The SLA Document is usually legally binding between a company and anoutsourcing vendor(s). The document describes the exact services andservice levels, with details about all agreements.

• The SLA Process represents the methods that the outsourcing vendor willuse to support the SLA document. The methods of supporting the SLAdocument are usually left to the outsourcing vendor to identify. Theseprocesses should be discussed and possibly identified during SLA contractnegotiation. It is important that both parties understand the processesand methods of support as well as the management and reporting tools.




• Service Level Agreements are often categorized in the following manner:

• Basic: A single level service agreement is in place. Metrics are established andmeasured, possibly requiring manual collection of data for management reporting.Objective is to justify the technical support operation.

• Medium: The automation of metrics data enables more comprehensive less laborintensive reporting of service level achievement. Introduction of cost recovery thatmaps to market rates and supported by service level reporting. Possible multi-levelservice agreements by cost per services rendered. Objective is to match serviceand cost levels with long term goal to increase service levels while decreasingcosts.

• Advanced: Service levels are embedded in overall service desk processes enablingdynamic allocation of resources either external or internal to meet changingbusiness conditions. Goal is to provide a seamless mix of services, costs andservice providers at better than competitive rates. Often enterprises at this levelare ready to extend services to the open market.



SLA – Service Level Agreement (4a)

Contacts and Role assignmentFirst, name the key contact to the Service Level Agreements and delegate SLA management tasks to others. Other contacts for the SLA include:ABC Company | Management | Exchange connection into other corporate systems:• Management of 3rd Party Outlook/Exchange Development• Application Development• Remote and Dial-in Access

ReportingThe frequency and detail of reports must be identified as well. Reporting can then be further broken down into two techniques:• ABC Company may also require that an automatic mechanism be put into place to notify the

named contacts when critical performance thresholds are met. Specific thresholds are discussed later in the document.

• Questionnaires and end-user canvassing methods should also be performed by ABC Company and/or the Outsourcing Company as part of an overall customer service initiative.

.



SLA – Service Level Agreement (4b)Finances

Payment terms and contract length are negotiated with the outsourcing vendor. ABC Company may prefer a contract length of six months, but will consider contracts as long as one year. Renewals can be handled in many ways including automatic six month extensions. Both ABC Company and the outsourcing vendor should be able to request a formal renewal meeting to update the SLA with riders and to negotiate new terms.

There are two types of terminations possible:

1.Contract Termination- Indicates that either ABC Company or the outsourcing company elects to terminate the contract. A “Technology Transfer” and associated fee would probably be required in order to shift the maintenance and support to another group.

2.Technology Termination- A termination in technology would occur when the support requirements are no longer required due to a shift in ABC Company technologies. This form of termination may or may not require a formal “Technology Transfer.”

Financial Incentive Plan

Most groups believe that the total cost of ownership (TCO) is more a function of cost of service and support of the system than a function of the cost of hardware and software. SLAs can drive down TCO by identifying damages for missed service levels.




Termination Options are described as follows:• Change Management

• Service Level Management is accomplished by negotiating a change or additional to an existing Service Level Agreement. Out-of-scope or new projects need not be discouraged. A change process occurs during every review process and can also be instigated as needed. Several things could require a change or addendum to the existing SLA:

– A change in the process workflow

– Additional services

– Missed performance or customer service thresholds

– Additional third-party applications

– Changes are not made directly to the SLA. Instead, contract riders are appended to the SLA until such time that the SLA is rewritten to incorporate the addendums. The SLA can only be written during a renewal cycle with both parties present.



SLA – Service Level Agreement (6a)Performance Level Guidelines

Inter-site Message Transfers

Because the outsourcing vendor may have little control over the stability of the hub servers, ABC Company may not require guaranteed delivery times for mail originating from, or addressed to, any mailbox outside of the ABC Company’s site. However, inbound Internet email with legitimate addresses should not get returned as undeliverable from the Exchange systems within the supported (environment?). The outsourcing vendor should remedy any internal Exchange process that returns mail.

Intra-site Message Transfers

ABC Company requires that intra-site Exchange mail be delivered to the recipient’s server-based mailbox within 15 minutes of delivery to a server within the supported site.

Remote Synchronization Performance

Off-line Address book

Remote users who replicate the Offline Address Book should never wait more than thirty minutes for a complete refresh to transfer over a 56K connection.

Mailbox Replication

You should probably define the mailbox limits. In many cases, mailboxes are classified into two or more categories. For example:

50MB Users have a 50MB limit on mailbox size | 75MB Users have a 75MB limit on mailbox size

Directory update frequency

Many companies configure directory replication so that the directory is current within a forty-eight hour time period. For example, a mailbox that is added at 3:00 p.m. on Tuesday must appear in the directory and Offline Address Book before 3:00 p.m. on Thursday. This should be defined in the SLA.



SLA – Service Level Agreement (6b)Performance Level Guidelines

System Changes

Administrative tasks, such as Exchange/NT username add/remove/change, should be able to be handled within one business day. The primary and backup responsibility may be divided up among the server support team and the helpdesk.

An matrix of administrative task groups and responsibilities should be created in order to identify the ability of each group, including:

• Add/Remove/Change of mailboxes and distribution lists

– One business day or less

• Public Folder Creation

– Two business days per request

• Exchange Gateway settings

– Two business days per request

• Updating permissions and security settings on Public Folders


• Assigning email addresses to a Public Folder


• Distribution List creation

– Two business days or less

• Distribution List modification


• Mailbox restoration (from tape)

– Three business days or less



The outsourcing company maywant to define the maximumnumber of one-day requests thatcan be filled per business day.Additional requests will roll to thenext business day and will takepriority over new requests.

SLA – Service Level Agreement (7a)Uptime Requirements

System availability can be an expensive requirement. It is important that we identify the specific requirements from a resource access standpoint and not necessarily on a server by server basis. The specifics dictate the availability of the servers.

Network and remote access

• Network connectivity between sites and for users should be defined clearly as to the required uptime. Redundant links may be required based on the connectivity requirements.

Mailbox Access

• This specification details the amount of time a user cannot access his/her mailbox on an Exchange server in the supported site. Many companies define at least two types of mailbox classifications:

• Class A users can be without access to their mailboxes for no more than six business hours. This group usually contains managers and key people within ABC Company

• Class B users can be without access to their mailboxes for no more than 24 business hours. This group represents the bulk of the ABC Company Exchange users.

Public Folder Access

• In order to maintain the OST consistency of applications, you should define how long Exchange users can be without a Public Folder. Some companies place this between 24 and 48 hours. However, you should request that, if restored, the Public Folders must contain all items as well as the most current items possible.

Inter-site directory

• In the case of a corrupt directory, replication may need to be forced in order to get the names and addresses of ABC Company mailboxes outside the supported site. The site should not be without access to the complete directory for more than 48 hours.

Intra-site directory

• In the case of a corrupt directory, intra-site replication may need to be forced in order to get the names and addresses of ABC Company mailboxes within the supported site. The supported site must not be without access to the complete directory list for more than 24 hours.



SLA – Service Level Agreement (7b)

Uptime RequirementsServer Availability

• Information gathered from the previous specifications dictate the level of availability that is required. The services are then classified using the following availability classes.



SYSTEM-TYPE AVAILABILITY CLASS

UNAVAILABILITY MINUTES/YEAR

SYSTEM AVAILABILITY

Unmanaged 1 50,000 90%

Managed 2 5,000 99.0%

Well-Managed 3 500 99.9%

Fault-Resilient 4 50 99.99%

High-Availability

SLA – Service Level Agreement (8a)Equipment Support Requirements

Access and Security

• ABC Company should require that named contacts be permitted physical access to the equipment at any given time. Moreover, overall access to the equipment must be secured and restricted. Access to the equipment must be available 24 hours a day, 7 days per week for the vendor’s support personnel.

Disaster Recovery Preparation

Backups

• Many companies require that the clients be able to request a "recovery of deleted items" for up to 30 days of deleted items. Moreover, backup tapes to the system should be placed in a 30 day rotation, then erased or destroyed. There should be no tapes that contain data over thirty days old.

• In some cases, there may be a need to recover items from tape. The outsourcing vendor should honor such a request from any of the named contacts on the SLA. The outsourcing vendor may accept requests from the user community for restores, but should then verify the request with the named ABC Company contacts.

Monitoring

• ABC Company does not have any specific requirements in regards to the types of systems (software) used to monitor the equipment.



SLA – Service Level Agreement (8b)Equipment Support Requirements

Staffing >> Certification and Experience

• ABC Company requires that at least one person supporting the systems have current MCSE status. At least two of the support personnel must be certified on the current version of Microsoft Exchange Server.

Exclusive/Nonexclusive use

• ABC Company requires that the resources that support the ABC Company Exchange systems be exclusive to ABC Company and not used for non-ABC Company projects or tasks.

Equipment >> Brand/Vendor

• While ABC Company has no requirements as to the brands or types of equipment used for the Exchange Server environment, ABC Company does require that the equipment be included on the Hardware Compatibility List for the current version of Microsoft BackOffice.

• The outsourcing vendor is responsible for the requisitions and costs associated with all equipment necessary to support the ABC Company Exchange Systems.

Spares for testing/recovery

• ABC Company requires that at least two entire servers be allocated for spare equipment and testing/recovery. The servers must match the current servers in production so that parts can be swapped and/or replaced. ABC Company further requires that the test equipment be updated as the production equipment and online at all times for testing.



SLA – Service Level Agreement (9)MOM 2005 SLA Scorecard for Exchange

http://www.msexchange.org/articles/MOM-2005-SLA-Scorecard-Exchange.html



Questions? Answers! Answers? Questions!

Dziękuję za uwagę, proszę o ocenę mojej sesji

PYTANIA PO SESJI / KONTAKT:

MAIL: [email protected] | MSG: [email protected]

JABBER: [email protected] | SKYPE: tjkoprowski

TWITTER/FACEBOOK/LINKEDIN: KoprowskiT

BLOGI:

ITPRO Anorak’s Vision: http://itblogs.pl/blogs/notbeautifulanymore/default.aspx [PL]

Volume Licensing Specialites: http://volumelicensingspecialites.wordpress.com [PL]

STRONY:

Społeczności IT: http://www.ms-groups.pl | Windows Server System: http://www.wss.pl

Virtual Study Portal: http://www.virtualstudy.pl | CodeGuru: http://www.codeguru.pl








http://itblogs.pl/blogs/notbeautifulanymore/default.aspx

http://volumelicensingspecialites.wordpress.com/

http://www.ms-groups.pl/



http://www.wss.pl/

http://www.virtualstudy.pl/

http://www.codeguru.pl/