Virtual Study Beta Exam 71-663 Exchange 2010 Designing And Deploying Messaging Compliance System Monitoring And Reporting
Upcoming SlideShare
Loading in...5
×
 

Virtual Study Beta Exam 71-663 Exchange 2010 Designing And Deploying Messaging Compliance System Monitoring And Reporting

on

  • 1,999 views

This is my presentation for VirtualStudy.pl as teh last part of preparation for 71-663 beta exam: 71-663: Pro: Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

This is my presentation for VirtualStudy.pl as teh last part of preparation for 71-663 beta exam: 71-663: Pro: Designing and Deploying Messaging Solutions with Microsoft Exchange Server 2010

Statistics

Views

Total Views
1,999
Views on SlideShare
1,994
Embed Views
5

Actions

Likes
1
Downloads
32
Comments
0

1 Embed 5

http://www.slideshare.net 5

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Virtual Study Beta Exam 71-663 Exchange 2010 Designing And Deploying Messaging Compliance System Monitoring And Reporting Virtual Study Beta Exam 71-663 Exchange 2010 Designing And Deploying Messaging Compliance System Monitoring And Reporting Presentation Transcript

  • 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 Koprowski aka 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
  • Design and deploy auditing and discovery. 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); identify requirements for discovery or auditing; plan journaling or message record management (MRM) for discovery; plan access permissions for discovery searches 2009-12-18 VirtualStudy.pl 3
  • Administrator Audit Logging You can use administrator audit logging in Microsoft Exchange Server 2010 to log when a user or administrator in your organization runs a cmdlet. By keeping a log of the 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. Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 4
  • Administrator Audit Logging By default, if audit logging is enabled, a log entry is created every time any cmdlet, other than a Get cmdlet, is run. When you configure audit logging, you need to specify the mailbox where you want logs to be stored. If you don't want to audit every cmdlet that's run, you can configure audit logging to audit only the cmdlets and parameters you're interested in. You configure audit logging with the Set-AdminAuditLogConfig cmdlet. The parameters 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. Parameters specified when the cmdlet was run and the values provided. If more than one Parameter 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. Date and time when the cmdlet was run. The date and time are stored in Coordinated Universal Run Date Time (UTC) format. Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 5
  • 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 audit logging for the first time and want this behavior, you don't have to change the cmdlet audit list. If you've previously specified cmdlets to audit and now want to audit all cmdlets, you can audit all cmdlets by specifying the wildcard character ( * ) with the AdminAuditLogCmdlets parameter on the 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 the AdminAuditLogCmdlets parameter. When you provide the list of cmdlets to audit, you can provide single cmdlets, cmdlets with wildcard characters ( * ), or a mix of both. Each entry in the list 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* Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 6
  • Administrator Audit Logging - cmdlets Specify the parameters to be audited By default, audit logging creates a log entry for every cmdlet that's run, regardless of the parameters that are specified. If you're enabling audit logging for the first time and want this behavior, you don't have to change the parameter audit list. If you've previously specified parameters to audit and now want to audit all parameters, you can do so by specifying the wildcard 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 AdminAuditLogParameters parameter. 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 by commas. 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 Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 7
  • Administrator Audit Logging - cmdlets Specify the auditing mailbox You can specify the SMTP address of the mailbox where you want to store administrator audit logs using the AdminAuditLogMailbox parameter on the Set-AdminAuditLogConfig cmdlet. The SMTP 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 david@contoso.com, use the following command: Set-AdminAuditLogConfig -AdminAuditLogMailbox david@contoso.com Enable administrator audit logging You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Administrator audit logging" entry in the Exchange and Shell Infrastructure Permissions topic. If you haven't previously configured administrator audit logging, you must specify the cmdlets and parameters to be audited and specify an auditing mailbox before you enable administrator audit logging. You can enable administrator audit logging by setting the AdminAuditLogEnabled parameter to $True on the Set-AdminAuditLogConfig cmdlet. For example, run the following command to enable administrator audit logging: Set-AdminAuditLogConfig -AdminAuditLogEnabled $True ||( $False) Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 8
  • RBAC – Role Based Access Control Role 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. Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 9
  • RBAC – Role Based Access Control (ITPro) Management Role Groups • Management role group The management role group is a special universal security group (USG) that contains mailboxes, users, USGs, and other role groups that are members of the role group. This is where you add and remove members, and it's also what management roles are assigned to. The combination of all the roles on a role group defines everything that users added to a role group can manage in the Exchange organization. • Management role A management role is a container for a grouping of management role entries. Roles are used to define the specific tasks that can be performed by the members of a role group that's assigned the role. A management role entry is a cmdlet, script, or special permission that enables each specific task in a role to be performed. • Management role assignment A management role assignment links a role and a role group. Assigning a role to a role group grants members of the role group the ability to use the cmdlets and parameters defined in the role. Role assignments can use management scopes to control where the assignment can be used. • Management role scope A management role scope is the scope of influence or impact on a role assignment. When a role is assigned with a scope to a role group, the management scope targets specifically what objects that assignment is allowed to manage. The assignment, and its scope, are then given to the members of the role group, and restrict what those members can manage. A scope can consist of servers, organizational units (OUs), or filters on server or recipient objects.. Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 10
  • RBAC – Role Based Access Control (EndUser) Management Role Assignment Policies Role assignment policies consist of the following components that define what users can do with their own mailboxes. Notice that some of the same components also apply to role groups. When used with role assignment 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 in Exchange 2010. Users are associated with the role assignment policy when their mailboxes are created or if you change the role assignment policy on a mailbox. This is also what you assign end-user management roles to. The combination of all the roles on a role assignment policy defines everything that the user can manage on his or her mailbox or distribution groups. • Management role A management role is a container for a grouping of management role entries. Roles are used to define the specific tasks that a user can do with his or her mailbox or distribution groups. A management role entry is a cmdlet, script or special permission that enables each specific task in a management 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 role assignment policy. Assigning a role to a role assignment policy grants the ability to use the cmdlets and parameters defined in the role. When you create a role assignment between a role assignment policy and a role, you can't specify any scope. The scope applied by the assignment is either Self or MyGAL. All role assignments are scoped to the user's mailbox or distribution groups. Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 11
  • 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. Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 12
  • 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 Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 13
  • Access permissions for discovery searches Multi-Mailbox Search can be a useful search and data collection tool for different audiences within 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 is increasingly becoming one of the most important tasks for organizations involved in lawsuits. Without a dedicated tool, searching messaging records spread over a number of different mailboxes, which reside in different mailbox databases on e-mail servers throughout a dispersed organization, can be a time-consuming and resource-intensive task. When receiving requests for messaging records pertaining to a certain subject, Multi-Mailbox Search can search a large volume of e-mail messages stored in mailboxes across one or more Exchange 2010 servers, and possibly in different locations. • Internal investigations Requests from managers or legal departments as part of internal investigations can be handled by Multi-Mailbox Search. • Human Resources monitoring Requests from HR departments as part of regular monitoring of e-mail content or specific searches based on HR requirements can be handled by Multi- Mailbox Search. Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 14
  • 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. Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 15
  • 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 mailbox other than the default Discovery Search Mailbox as the target mailbox, you must assign mailbox access permissions to authorized users to allow them to access that discovery mailbox. Authorized users with mailbox access permissions can access the mailbox using 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 mailbox searched to store messages returned from that mailbox. The mailbox user's display name along with the date and time of search creation is used for the folder name. Messages are copied to a folder with the same name as their location in the searched mailbox. For example, if the search name is Discovery-ProjectContoso, and a message located in the Inbox folder in Paul Shen's primary mailbox is returned, the folder hierarchy created in the discovery mailbox would be Discovery-ProjectContoso -> Paul Shen-9/4/2009 3:57:10 PM -> Primary Mailbox > Inbox. Any message flags, including read/unread status and follow-up flags, are maintained. 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 who performed it. Information captured about basic logging appears in the body of the e-mail message sent to the mailbox where 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 a comma-separated value (CSV) file attached to the e-mail message that contains basic logging information. The name of the search is used for the CSV file name. This information may be required for compliance or record-keeping purposes. To enable full logging, you must select Enable full logging in the EMC, or specify the logging level using the LoggingLevel parameter in the Shell. Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 16
  • 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 the user 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 meet the 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 servers in the organization. Search results will be saved in the mailbox Discovery Search Mailbox, in a folder with the same 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 SearchResults@contoso.com Get-Mailbox -Resultsize unlimited -Filter {RecipientTypeDetails -eq "DiscoveryMailbox"} Set-Mailbox joe@contoso.com -LitigationHoldEnabled $true | $false Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 17
  • Design and deploy message archival. This objective may include but is not limited to: dumpster 2.0; legal hold; retention policies (MRM); retention tags; long-term backup; design and deploy managed folders; design and deploy alternate mailboxes; plan for managing messages in default Outlook folders; plan for managing messages in custom managed folders; plan a retention policy implementation; plan an AutoTagging implementation 2009-12-18 VirtualStudy.pl 18
  • Dumpster 2.0 The 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. Design and deploy message archival. 2009-12-18 VirtualStudy.pl 19
  • 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. Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 20
  • MRM – Retention Policies (obrazkowo) Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 21
  • MRM – Retention Policies (obrazkowo) Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 22
  • 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 Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 23
  • 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. Design and deploy auditing and discovery. 2009-12-18 VirtualStudy.pl 24
  • AutoTagging Use 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 Design and deploy message archival. 2009-12-18 VirtualStudy.pl 25
  • AutoTagging Parameter Required Type Description The Identity parameter specifies the mailbox. You can use one of the following values: GUID DistinguishedName (DN) Microsoft.Exchange.Con DomainAccount Identity Required figuration.Tasks.MailboxI User principal name (UPN) dParameter LegacyExchangeDN SmtpAddress Alias System.Management.Au The Confirm switch causes the command to pause processing and requires you to Confirm Optional tomation.SwitchParamet acknowledge what the command will do before processing continues. You don't have to er specify a value with the Confirm switch. DomainCont Microsoft.Exchange.Dat The DomainController parameter specifies the fully qualified domain name (FQDN) of the Optional roller a.Fqdn domain controller that writes this configuration change to Active Directory. System.Management.Au IgnoreDefaul Optional tomation.SwitchParamet The IgnoreDefaultScope parameter isn't available in this release. tScope er The RetentionAutoTaggingEnabled parameter specifies whether to enable retention RetentionAut AutoTagging. oTaggingEna Optional System.Boolean You can use one of the following values: bled •$true This value enables AutoTagging. •$false This value disables AutoTagging. System.Management.Au The WhatIf switch instructs the command to simulate the actions that it would take on the WhatIf Optional tomation.SwitchParamet object. By using the WhatIf switch, you can view what changes would occur without having er to apply any of those changes. You don't have to specify a value with the WhatIf switch. Design and deploy message archival. 2009-12-18 VirtualStudy.pl 26
  • Design and deploy transport rules for message compliance This objective may include but is not limited to: RMS; ethical firewall; message journaling; disclaimers; mail tips, such as notification for external recipients and recipient limits 2009-12-18 VirtualStudy.pl 27
  • Alert Modify Protect Redirect “Allow delivery “Allow delivery “Allow delivery “Block delivery but add a but modify but prevent and redirect.” warning.” message.” forwarding.” LESS RESTRICTIVE MORE RESTRICTIVE Classify Append Review Block “Allow delivery “Allow delivery “Block delivery “Do not but apply but add a until reviewed.” deliver.” classification.” disclaimer.” • Apply the right level of control based on the sensitivity of the data • Maximize control and minimize unnecessary user disruptions Design and deploy transport rules for message compliance 2009-12-18 VirtualStudy.pl 28
  • Alert users about potential risks Design and deploy transport rules for message compliance Design and deploy transport rules for message compliance 2009-12-18 VirtualStudy.pl 29
  • Easily enforce Transport Rules granular policies • 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 Design and deploy transport rules for message compliance 2009-12-18 VirtualStudy.pl 30
  • Fine tune rules with Conditions detailed criteria 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) Design and deploy transport rules for message compliance 2009-12-18 VirtualStudy.pl 31
  • Apply the appropriate Actions level of control 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 Design and deploy transport rules for message compliance 2009-12-18 VirtualStudy.pl 32
  • Granular protection that travels with the data Information Rights Management (IRM) provides persistent protection to control who can access, forward, print, or copy sensitive data within an e-mail. • 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 Design and deploy transport rules for message compliance 2009-12-18 VirtualStudy.pl 33
  • Transport Protection Rules Automatically apply IRM Apply RMS policies automatically using Transport Rules Apply “Do Not Forward” or custom RMS templates IRM protection can be triggered based on sender, recipient, content and other conditions | Office 2003, 2007, and 2010 attachments also protected Design and deploy transport rules for message compliance 2009-12-18 VirtualStudy.pl 34
  • Outlook Protection Rules Provide users more IRM protection options Adding recipient or distribution list can trigger IRM protection automatically before sending User can be granted option to turn off rule for IRM protection can still be applied manually non-sensitive e-mail Design and deploy transport rules for message compliance 2009-12-18 VirtualStudy.pl 35
  • IRM in Outlook Web App Read and reply to protected messages Native support for IRM in OWA eliminates need for Access to standard and Internet Explorer Rights Management add-on custom RMS templates Office documents also protected Design and deploy transport rules for message compliance 2009-12-18 VirtualStudy.pl 36
  • Protected Voice Mail Prevent forwarding of voice mail “Do Not Forward” template • Integration with AD RMS and Exchange Unified Messaging • Permissions designated by sender (by marking the message as private) or by administrative policy Design and deploy transport rules for message compliance 2009-12-18 VirtualStudy.pl 37
  • IRM Decryption Enable scanning, filtering, journaling Infected messages and spam can be filtered Protected messages sent to transport server Messages are re-encrypted and delivered Messages and attachments decrypted to enable content Journaled messages include filtering, transport rules decrypted clear-text copy Design and deploy transport rules for message compliance 2009-12-18 VirtualStudy.pl 38
  • Protection and Control Scenarios Restrict e-mail between • Transport rules to block mail between specific users Ethical Wall analysts and brokers or groups Manager required to sign-off on • Send to manager for approval Supervision mail to sensitive partner • MailTips for moderated recipients HR Policy Inappropriate content • Filter for keywords and block, redirect, modify HIPAA (health data) • Apply MailTips to alerts for external recipients GLBA (financial data) • Apply IRM protection to control access Privacy PIPEDA (Canada) • Monitor for credit card numbers and other PCI (Worldwide) personally identifiable information (PII) • Append disclaimer that includes name, title, Signatures EUPD 2003/58/EC department, etc. Design and deploy transport rules for message compliance 2009-12-18 VirtualStudy.pl 39
  • IPC with Exchange Server 2010 Automatically monitor and control the distribution of sensitive information Ensure the right level of control is applied to the right messages Better protect access to data with persistent Information Rights Management Design and deploy transport rules for message compliance 2009-12-18 VirtualStudy.pl 40
  • Design and deploy for monitoring and reporting. This objective may include but is not limited to: design and deploy message flow monitoring; client accessibility; SLA requirements, such as percent of email delivered in a certain amount of time within the organization; analyze message usage, number of messages, and message size; analysis and design of ongoing infrastructure improvements due to increased capacity, performance, and requested features; monitoring client access services; troubleshooting client access services 2009-12-18 VirtualStudy.pl 41
  • Message Flow Monitoring Use the Test-Mailflow cmdlet to diagnose whether mail can be successfully sent from and delivered to the system mailbox on a computer that has the Mailbox server role installed. You can also use this cmdlet to verify that e-mail is sent between Mailbox servers 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>]] Design and deploy message archival. 2009-12-18 VirtualStudy.pl 42
  • Message Flow Monitoring Parameter Required Type Description System.Management. The AutoDiscoverTargetMailboxServer parameter specifies whether to automatically AutoDiscoverTargetM Required Automation.SwitchPa populate a list of target Mailbox servers to which to send a test message. The task queries ailboxServer rameter Active Directory to discover all Mailbox servers and then sends each server a test message. Microsoft.Exchange.C The TargetDatabase parameter specifies the mailbox database to which test messages are TargetDatabase Required onfiguration.Tasks.Da sent. tabaseIdParameter The TargetEmailAddress parameter specifies the SMTP address of the mailbox to which test TargetEmailAddress Required System.String 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. Microsoft.Exchange.C The TargetMailboxServer parameter specifies one or more Mailbox servers in the local TargetMailboxServer Required onfiguration.Tasks.Ser Exchange organization to which test messages are sent. verIdParameter ActiveDirectoryTimeo The ActiveDirectoryTimeout parameter specifies the number of seconds that elapse before Optional System.Int32 ut the task provides an informational message about the delay. The default value is 15 seconds. System.Management. The Confirm switch causes the command to pause processing and requires you to Confirm Optional Automation.SwitchPa acknowledge what the command will do before processing continues. You don't have to rameter specify a value with the Confirm switch. Microsoft.Exchange.D The DomainController parameter specifies the fully qualified domain name (FQDN) of the DomainController Optional ata.Fqdn domain controller that retrieves data from Active Directory. Design and deploy message archival. 2009-12-18 VirtualStudy.pl 43
  • Message Flow Monitoring Parameter Required Type Description 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 ErrorLatency Optional System.Int32 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. 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 ExecutionTimeout Optional System.Int32 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. Microsoft.Exchange.C The Identity parameter specifies the source Mailbox server name or source mailbox SMTP Identity Optional onfiguration.Tasks.Ser address from which a test message is sent. The default value is the local Mailbox server. verIdParameter 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 MonitoringContext Optional System.Boolean populates the MonitoringContext object with events and performance counters used by System Center Operations Manager 2007. The default value of this parameter is $false. TargetEmailAddressDi The TargetEmailAddressDisplayName parameter specifies the display name of the mailbox to Optional System.String splayName which test messages are sent. System.Management. The WhatIf switch instructs the command to simulate the actions that it would take on the WhatIf Optional Automation.SwitchPa object. By using the WhatIf switch, you can view what changes would occur without having rameter to apply any of those changes. You don't have to specify a value with the WhatIf switch. Design and deploy message archival. 2009-12-18 VirtualStudy.pl 44
  • SLA – Service Level Agreement (1) • There are two major parts to an SLA: the governing document and the process. • The SLA Document is usually legally binding between a company and an outsourcing vendor(s). The document describes the exact services and service levels, with details about all agreements. • The SLA Process represents the methods that the outsourcing vendor will use to support the SLA document. The methods of supporting the SLA document are usually left to the outsourcing vendor to identify. These processes should be discussed and possibly identified during SLA contract negotiation. It is important that both parties understand the processes and methods of support as well as the management and reporting tools. Design and deploy for monitoring and reporting. 2009-12-18 VirtualStudy.pl 45
  • SLA – Service Level Agreement (2) • Service Level Agreements are often categorized in the following manner: • Basic: A single level service agreement is in place. Metrics are established and measured, 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 labor intensive reporting of service level achievement. Introduction of cost recovery that maps to market rates and supported by service level reporting. Possible multi-level service agreements by cost per services rendered. Objective is to match service and cost levels with long term goal to increase service levels while decreasing costs. • Advanced: Service levels are embedded in overall service desk processes enabling dynamic allocation of resources either external or internal to meet changing business conditions. Goal is to provide a seamless mix of services, costs and service providers at better than competitive rates. Often enterprises at this level are ready to extend services to the open market. Design and deploy for monitoring and reporting. 2009-12-18 VirtualStudy.pl 46
  • SLA – Service Level Agreement (3) Design and deploy for monitoring and reporting. 2009-12-18 VirtualStudy.pl 47
  • SLA – Service Level Agreement (4a) Contacts and Role assignment First, 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 Reporting The 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. . Design and deploy for monitoring and reporting. 2009-12-18 VirtualStudy.pl 48
  • 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. Design and deploy for monitoring and reporting. 2009-12-18 VirtualStudy.pl 49
  • SLA – Service Level Agreement (5) 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. Design and deploy for monitoring and reporting. 2009-12-18 VirtualStudy.pl 50
  • 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. Design and deploy for monitoring and reporting. 2009-12-18 VirtualStudy.pl 51
  • 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 The outsourcing company may – One business day or less • Assigning email addresses to a Public Folder want to define the maximum – One business day or less number of one-day requests that • Distribution List creation can be filled per business day. – Two business days or less • Distribution List modification Additional requests will roll to the – One business day or less next business day and will take • Mailbox restoration (from tape) priority over new requests. – Three business days or less Design and deploy for monitoring and reporting. 2009-12-18 VirtualStudy.pl 52
  • 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. Design and deploy for monitoring and reporting. 2009-12-18 VirtualStudy.pl 53
  • SLA – Service Level Agreement (7b) Uptime Requirements Server 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 UNAVAILABILITY SYSTEM CLASS MINUTES/YEAR 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 Design and deploy for monitoring and reporting. 2009-12-18 VirtualStudy.pl 54
  • 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. Design and deploy for monitoring and reporting. 2009-12-18 VirtualStudy.pl 55
  • 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. Design and deploy for monitoring and reporting. 2009-12-18 VirtualStudy.pl 56
  • SLA – Service Level Agreement (9) MOM 2005 SLA Scorecard for Exchange http://www.msexchange.org/articles/MOM-2005-SLA-Scorecard-Exchange.html Design and deploy for monitoring and reporting. 2009-12-18 VirtualStudy.pl 57
  • Questions? Answers! Answers? Questions! Dziękuję za uwagę, proszę o ocenę mojej sesji PYTANIA PO SESJI / KONTAKT: MAIL: KoprowskiT@windowslive.com | MSG: KoprowskiT@windowslive.com JABBER: KoprowskiT@alfa.incenti.net.pl | 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 Design and deploy for monitoring and reporting. 2009-12-18 VirtualStudy.pl 58