Как фильтровать отправителей без ввода полного домена в get-messagetrackinglog?

Как фильтровать отправителей без ввода полного домена в get-messagetrackinglog?

Как фильтровать отправителей без ввода полного домена в get-messagetrackinglog?
by Pavel Nagaev on 13/05/2016 in PowerShell, Трекинг сообщений
В Microsoft Exchange Server существует несколько способов отслеживания сообщений. Самым эффективным и гибким из них является трекинг с помощью командлета Get-MessageTrackingLog. Вся гибкость поиска сообщений проявляется если администратор имеет определенные навыки при работе в PowerShell, но у Get-MessageTrackingLog есть один недостаток.  Встроенная фильтрация по отправителю или получателю требует ввода полного адреса отправителя, wildcard символы, типа звёздочек не поддерживаются.
Это очень неудобно, т.к. зачастую пользователи обращаются с просьбой посмотреть не приходило ли письмо от какого-нибудь туристического агенства или фирмы у которых известен только домен. Но в PowerShell конечно же есть решение.Давайте рассмотрим пример использования звёздочек.
Get-MessageTrackingLog -Start "05/23/2011" -Sender "*travel*"
Но получаем ошибку.
Specified proxy address «*travel*» is invalid: «*travel*» isn’t a valid SMTP address. The domain name can’t contain spaces and it has to have a prefix and a suffix, such as example.com.
Поскольку «напрямую » это неудобно, то можно воспользоваться командой where-object
Get-MessageTrackingLog -Start “03/01/2014” -ResultSize Unlimited |where-object {$_.Sender -like "*travel*"}|
select-object timestamp,eventid,messageid,sender,recipients,messagesubject | out-gridview
В вышеприведенном коде мы отбираем все записи из трекинга сообщений, начиная с 1 марта 2014 года, затем выбираем из них те, у которого отправитель содержит подстроку «*travel*» и выводим определенные поля в графическую таблицу.
Средство Out-gridview даст нам возможность удобно прокручивать, сортировать и фильтровать данные. Чтобы out-grid работал, необходимо установить оболочку PowerShell ISE.
Выглядит это примерно так:



проверка SMTP сервера через Telnet

Для авторизации на почтовом сервер с с помощью AUTH LOGIN, нам нужно преобразовать имя и пароль пользователя, из-под которого будет отправляться письмо в формат Base64. Это можно сделать с помощью скриптов или онлайн сервисов. Я воспользоваться сайтом https://www.base64encode.org/ или https://calcus.ru/base64.

Имя пользователя:  testuser@contoso.com, в кодировке  Base64 получилось: dGVzdHVzZXJAY29udG9zby5jb20=

Пароль: $up3RsTr)ng — в Base64 JHVwM1JzVHIpbmc=

конвертация имени и пароля в формат base64

Теперь в командой строке с помощью Telnet подключаемся на 25(SMTP) порт нашего почтового сервера (вводимые команды я буду выделять синим цветов):

telnet mail.contoso.com 25

Если это Exchange, он вернет что-то вроде;

220 mail.contoso.com Microsoft ESMTP MAIL Service ready at Thu, 10 Aug 2015 14:25:30 +0300

Представимся:

ehlo sender.contoso.com

Сервер вернет список поддерживаемых типов авторизаций и возможностей. Как вы видите базовая авторизация (AUTH LOGIN) в списке имеется.

250-mail.contoso.com Hello [192.168.100.15]
250-SIZE 36700160
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH LOGIN
250-8BITMIME
250-BINARYMIME
250 CHUNKING

Сообщаем SMTP серверу, что мы хотим авторизоваться с помощью имеющейся учетной записи:

AUTH LOGIN

Сервер должен ответить:
334 VXNlcm5hbWU6

Теперь вставляем имя пользователя в формате Base64, которое мы закодировали ранее:
dGVzdHVzZXJAY29udG9zby5jb20=

Сервер должен ответить:

334 UGFzc3dvcmQ6.

Теперь пора вставить пароль в формате Base64:
JHVwM1JzVHIpbmc=

Если имя и пароль пользователя верны, сервер ответит.
235 2.7.0 Authentication successful

Если нет:

535 5.7.8 Error: authentication failed: UGFzc3dvcmQ6

отправка письма из telnet с smtp аутентификацией - 235 2.7.0 Authentication successful

Теперь можно заполнить стандартные поля письма:

mail from: testuser@contoso.com
250 2.1.0 Sender OK
rcpt to: admin@contoso.com
250 2.1.5 Recipient OK
data
354 Start mail input; end with .
from: TestUserovich <testuser@contoso.com>
to: TheAdmin < admin@contoso.com >
Subject: Test BASE SMTP Authenticated via Telnet
This is test
.
250 2.6.0 <ae80548d-cb8a-4c79-ad80-55b1190df753@mail.contoso.com> [InternalId=6384384] Queued mail for delivery

отправка письма из командной строки с выполнением ауторизации на сервере smtp

QUIT

221 2.0.0 Closing connection.
Connection closed by foreign host.



Запрет изменения личной информации в Exchange OWA 2010

Exchange 2010 Role Based Access Control (Part 4)

by [Published on 27 July 2010 / Last Updated on 27 July 2010]

A look at the new Role Based Access Control model in Exchange 2010.

If you would like to read the other parts in this article series please go to:

Introduction

In this article series you have seen how users can be added to management role groups to grant them permissions to run the cmdlets that are linked to the management role groups. This method is typically used to grant administrators and specialist users the permissions that they need to perform their duties. For normal users who are not administrators or specialist users, management role assignment policies can be used. These management role assignment policies are typically used to grant users permissions to manage their own mailboxes as we shall see within this part of the overall RBAC article series.

Management Role Assignment Policies

All mailboxes are assigned a default role assignment policy unless a specific role assignment policy is otherwise specified. The default role assignment policy is named, rather unsurprisingly, Default Role Assignment Policy and its link to a mailbox can be seen by examining the output of any mailbox and looking for the RoleAssignmentPolicy attribute. For example, to examine the configuration of the mailbox belonging to the user Neil and filter the output for the RoleAssignmentPolicy attribute, the following cmdlet can be used:

Get-Mailbox Neil | fl RoleAssigmentPolicy

The result of running this cmdlet can be seen in Figure 14.


Figure 14: Default Role Assignment Policy

We will shortly examine the contents of the Default Role Assignment Policy to see what it contains and which permissions are granted. However, although we won’t be covering the creation of custom role assignment policies within this particular article series, it is worth covering at this point how you can change the management role assignment policy that is linked to a mailbox. For an existing mailbox, you can use the Set-Mailbox cmdlet with theRoleAssigmentPolicy parameter to change the management role assignment policy. For example, to set Neil’s mailbox to use a management role assignment policy called New Policy the following cmdlet could be used:

Set-Mailbox Neil –RoleAssignmentPolicy ‘New Policy’

For new mailboxes, the RoleAssignmentPolicy parameter of the New-Mailbox cmdlet can be used to specify the name of the management role assignment policy to be used when that mailbox is first created. If no specific policy name is applied when creating a new mailbox, the default management role assignment policy will be applied.

Management Role Assignments

If you have been reading the previous parts of this article series, you will remember that management role assignmentsare links between management role groups and management roles. In the context of management role assignment policies, management role assignments are also used and function as the link between management roles and management role assignment policies. You will also remember that management roles essentially hold a group of cmdlets that the user is allowed to run.

Let’s take a closer look at the Default Role Assignment Policy and see which management role assignments are linked to it. Ordinarily, you might be tempted to bring up the properties of the Default Role Assignment Policy via a cmdlet such as:

Get-RoleAssignmentPolicy –Identity ‘Default Role Assignment Policy’

The result of running this cmdlet can be seen in Figure 15.


Figure 15: Properties of the Default Role Assignment Policy

As you can see from Figure 15, the output does present some useful information such as the description of the policy but it doesn’t really tell you anything meaningful such as the management role assignments linked to the policy. To get this information, we can use the Get-ManagementRoleAssigment cmdlet together with the RoleAssignee parameter. By specifying the RoleAssignee as the Default Role Assignment Policy, we can see all management role assignments that are linked with the default policy. Ordinarily, a lot of information is returned when executing this cmdlet so in the example cmdlet below we can filter the output to only present the name and role information:

Get-ManagementRoleAssignment –RoleAssignee ‘Default Role Assignment Policy’ | fl Name,Role

You can see the result of running this cmdlet in Figure 16:


Figure 16: Assigned Management Roles

Management Roles

The output of Figure 16 shows you that the management role assignment policy called Default Role Assignment Policy is linked with five management roles called MyBaseOptions, MyContactInformation, MyVoiceMail, MyTextMessagingand MyDistributionGroupMembership.

Each of these management role names should be reasonably self-explanatory in what the roles are designed to allow the user to do but the table below serves to emphasize this information as it contains the five management role names together with their default descriptions.

Management Role Description
MyBaseOptions This role enables individual users to view and modify the basic configuration of their own mailbox and associated settings.
MyContactInformation This role enables individual users to modify their contact information, including address and phone numbers.
MyVoiceMail This role enables individual users to modify their voice mail settings.
MyTextMessaging This role enables individual users to create, view, and modify their text messaging settings.
MyDistributionGroupMembership This role enables individual users to view and modify their membership in distribution groups in an organization, provided that those distribution groups allow manipulation of group membership.

Table 1: Assigned Management Role DescriptionsIn order to keep this article reasonably short, let us now focus on looking deeper at just one of the management roles listed in Table 1, namely the MyContactInformation management role. In Figure 11 in part three of this article series we saw the generic Exchange Control Panel page within Outlook Web App.  In the centre of this screen it is possible to click the Edit button to allow the editing of the user’s own contact information as you can see from Figure 17.


Figure 17: Editing Contact Information

The ability for the users to edit their own contact information is made possible by the fact that the MyContactInformation management role is assigned to the users. Let’s take a deeper look at how the MyContactInformation management role is constructed. First of all, let’s take a closer look at the actual management role assignment calledMyContactInformation-Default Role Assignment Policy that you can see listed in Figure 16. To do this, we can run the following cmdlet:

Get-ManagementRoleAssignment ‘MyContactInformation-Default Role Assignment Policy’ | fl

You can see the result of running this cmdlet in Figure 18.


Figure 18: Management Role Assignment Details

You may remember from earlier in this article series that the Mailbox Search-Discovery Management role assignment had RecipientReadScope and RecipientWriteScope values of Organization, meaning that the scope of this management role assignment is set across the entire Exchange organization. Compare that information to the RecipientReadScope and RecipientWriteScope values seen in Figure 18 above, where you will see that the scopes for the MyContactInformation-Default Role Assignment Policy management role assignment are set to Self, meaning that the assigned roles can only modify the local mailbox information rather than the entire Exchange organization. This makes sense, as you may remember right back in part one of this article series that we said management role groups are used for overall administrators or specialist users, whereas management role assignment policies are used for the users themselves; clearly an individual user only requires permissions to modify his or her own information.

As for the actual cmdlets that the user will be able to run, we can examine this information by using the Get-ManagementRole cmdlet to examine the properties of the MyContactInformation management role and filter the output to show only the RoleEntries parameter. A suitable cmdlet is:

Get-ManagementRole MyContactInformation | fl RoleEntries

You can see the result of running this cmdlet in Figure 19.


Figure 19: The MyContactInformation Management Role

You can see from Figure 19 that this management role grants the user the rights to run the Set-User cmdlet with many different parameters such as the City, MobilePhone, Office and PostalCode parameters. It also grants the user the right to run the Get-Mailbox cmdlet with the Identity parameter. You may also remember from part three of this article series that it is easier to use the Get-ManagementRoleEntry cmdlet to display this information. For example, the following cmdlet could be used:

Get-ManagementRoleEntry MyContactInformation\* | ft –AutoSize -Wrap

The result of running this cmdlet is shown in Figure 20 where you can see that the cmdlet and parameter information is displayed much more clearly.


Figure 20: Get-ManagementRoleEntry Results

To demonstrate that the MyContactInformation management role in conjunction with the management role assignment does indeed allow a user to edit their own contact information, let’s prove this by removing the management role assignment. You probably will not want to do this in your production environment but this exercise can be useful to understand how all the various RBAC components work together. Consider Figure 21 where you can see that we first confirm that the Default Role Assignment Policy contains the management role assignment called MyContactInformation-Default Role Assignment Policy.

Next, the management role assignment policy can be removed via this cmdlet:

Remove-ManagementRoleAssignment ‘MyContactInformation-Default Role Assignment Policy’

The Get-ManagementRoleAssignment cmdlet is then re-run to confirm that the management role assignment is no longer available.


Figure 21: Removing the Management Role Assignment

The result of making this change is that, the next time the user logs onto OWA and attempts to edit their own contact information, it is not possible to edit the various fields as you can see from Figure 22.


Figure 22: Unable to Edit Contact Information

Summary

That concludes this four-part article series on an introduction to the RBAC model within Exchange 2010. In this article series you have seen how management role groups and management role assignment policies are used to assign permissions within Exchange 2010. I’ve taken the time to look at a specific management role group and a specific management role assignment policy, and broken these down into the various components in order to understand how they are used to assign permissions. This will allow future articles on customized solutions to be better understood.

If you would like to read the other parts in this article series please go to:



Запрет отправки писем с внешнего IP от имени своего домена.

Prevent Spam Mail From Your Own Domain in Exchange 2007

Posted on March 8, 2010 by Alan Hardisty

One of the biggest bug-bears with spam is the spam that comes from (or supposedly comes from) random_username@yourdomain.com or even your_username@yourdomain.com. This is known as spoofed mail and is a common technique that spammers use to try to get mail past Anti-Spam software.

From the Anti-Spam logs on my own server in the last 24-hours, I have received 1,974 emails (out of 17,432 in total) where the sender domain matched the recipient domain. This is about 11.3% of all mail that hit my server, so it is a relatively large problem. Factor that up to a year’s worth of mail and you get 720,510 a year.

To prevent this from happening, you simply need to remove a specific permission that allows anonymous senders to use your internal domain names in the Mail From section of an email. If anyone tries to do this (anonymous users only) they will receive a “550 5.7.1 Client does not have permissions to send as this sender” message.

The syntax to remove the permission should be entered as follows in the Exchange Management Console:

Get-ReceiveConnector “My Internet Receive Connector” | Get-ADPermission -user “NT AUTHORITY\Anonymous Logon” | where {$_.ExtendedRights -like “ms-exch-smtp-accept-authoritative-domain-sender”} | Remove-ADPermission

(You need to change the “My Internet Receive Connector” part in the above syntax)

Having run this command successfully, test using Telnet to your mail server from an external computer and see what happens if you try to send mail as one of your internal domain names. You should receive the 550 5.7.1 Message.

N.B. To put the permission back (in case you need to), please run the following:
Get-ReceiveConnector “My Internet Receive Connector” | Get-ADPermission -user “NT AUTHORITY\Anonymous Logon” | where {$_.ExtendedRights -like “ms-exch-smtp-accept-authoritative-domain-sender”} | Add-ADPermission

If you have internal photocopiers and other hardware that needs to relay via your Exchange 2007 server and you cannot configure them with a username / password, then removing the above permissions will prevent you from relaying and will cause you problems.



Управление правилами почтового ящика в Exchange Server 2010

Командлет, используемый для получения списка называется Get-InboxRule:

Get-InboxRule –Mailbox <MailboxUser>

Если вы хотите увидеть какое то определенное правило, используйте команду

Get-InboxRule –Mailbox <MailboxUser> -Identity “<Rule-Name>”

Для более удобного просмотра правил, используйте следующую конструкцию:

Get-InboxRule –Mailbox <MailboxUser> | Select Name, Description | fl

Теперь посмотрим на правило более детально с помощью командлета:

Get-InboxRule –Mailbox Anderson -Identity “Subject contains ‘Payroll’”

Теперь мы знаем нужные нам атрибуты, от нашего руководителя знаем какие значения необходимо им присвоить, займемся этим:

Set-InboxRule -Mailbox Anderson -Identity "Subject contains ‘Payroll’" -ApplyCategory {Red Category} -MarkImportance 2

Отключение или удаление правил

У нас также есть возможность отключать или удалять правила.  Предположим что наш руководитель опять изменил свое мнение (бывает у них такое, что поделать) и теперь он не хочет что с сообщениями содержащими слово Payroll просходили какие-либо изменения. Мы можем выполнить это просто отключив правило с помощью следующего командлета:

Disable-InboxRule -Mailbox Anderson -Identity "Subject contains ‘Payroll’"

Если вы хотите полностью удалить правило, процесс очень похож, отличает лишь командлет. Используйте:

Remove-Inboxrule –Mailbox <MailboxName> -Identity “<Inbox Rule name>”


перенаправление почты на внешний домен.

Configure Remote Domain Properties

https://technet.microsoft.com/en-us/library/bb124931.aspx
Exchange 2010
3 out of 5 rated this helpful — Rate this topic
 Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2Topic Last Modified: 2011-04-28

Remote domains are SMTP domains that are external to your Microsoft Exchange organization. You can create remote domain entries to define the settings for message transfer between your Exchange organization and domains outside your Active Directory forest. The settings for remote domains are global configuration settings for the Exchange organization.

Looking for other management tasks related to transport servers? Check out Managing Transport Servers.

 

You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the «Remote domains» entry in the Transport Permissions topic.

  1. In the console tree, navigate to Organization Configuration > Hub Transport.
  2. In the work pane, select the Remote Domains tab on the right, and then double-click the remote domain you want to configure.
  3. Use the General tab to configure the settings that determine the types of out-of-office messages sent to recipients in the remote domain. The type of out-of-office messages available in your organization depends on both the Exchange client version and the Exchange server version. The out-of-office message is set on the client and is sent by the server. Exchange Server 2010 and Exchange Server 2007 can send different out-of-office messages to internal and external users. Users that use Microsoft Office Outlook 2007 can set different internal and external out-of-office replies. Earlier versions of Outlook or Exchange only support a single type of out-of-office message used for both internal and external recipients.The General tab shows the following:
    • Domain name   Shows the display name for the domain.
    • Modified   Shows the date and time when the remote domain properties were last modified.
    • Allow none   If you select this option, no out-of-office messages are delivered to the remote domain.
    • Allow external out-of-office messages only   If you select this option, only out-of-office messages configured as external by an Outlook 2007 client, or by using Microsoft Office Outlook Web App for a mailbox located on an Exchange 2010 or Exchange 2007 Mailbox server are delivered to the remote domain.
    • Allow external out-of-office messages and legacy out-of-office messages (configured by using Outlook 2003 or earlier clients, or configured on Exchange 2003 mailboxes)   If you select this option, out-of-office messages configured as external by an Outlook 2007 client or by using Outlook Web App for a mailbox located on an Exchange 2010 Mailbox server are delivered to the remote domain. Out-of-office messages set by Outlook 2003 or earlier clients, regardless of the server version of their mailbox store, are delivered to the remote domain. Out-of-office messages sent by Exchange 2003 or earlier servers, regardless of the client version used to set the out-of-office message, are delivered to the remote domain.
    • Allow internal out-of-office messages and legacy out-of-office messages (configured by using Outlook 2003 or earlier clients, or configured on Exchange Server 2003 mailboxes)   If you select this option, out-of-office messages configured as internal by an Outlook 2007 client or by using Outlook Web App for a mailbox located on an Exchange 2010 Mailbox server are delivered to the remote domain. Out-of-office messages set by Outlook 2003 or earlier clients, regardless of the server version of their mailbox store, are delivered to the remote domain. Out-of-office messages sent by Exchange 2003 or earlier servers, regardless of the client version used to set the out-of-office message, are delivered to the remote domain.
  4. Use the Message Format tab to specify message policy, format, and character sets for the messages sent to this remote domain.Use the Message Format Options section to specify message delivery and formatting:
    • Allow automatic replies   To allow messages that are automatic replies from client e-mail programs in your organization, select this option.
    • Allow automatic forward   To allow messages that are auto-forwarded by client e-mail programs in your organization, select this option.
    • Allow delivery reports   To allow read receipts from client software in your organization to the remote domain, select this option.
    • Allow non-delivery reports   To allow non-delivery reports (NDRs) from your organization, select this option.
    • Display sender’s name on messages   To have the sender’s display name appear on messages, select this option. We recommend that you leave this option selected.
    • Use message text line wrap at column   To allow line wrap in message text for outgoing messages, select this option, and then in the text box, type the line-wrap size, from 0 through 132. To set the value to unlimited, leave the field blank. The default value is unlimited (blank).
    • Always use   To always send messages that use Exchange rich-text format, select this text box.
    • Never use   To never send messages that use Exchange rich-text format, select this check box.
    • Determined by individual user settings   To send e-mail messages that use the Exchange rich-text settings specified by the Outlook user, select this check box.

    Use the following character set options to specify acceptable character sets:

    • MIME character set   To identify a MIME character set, type the character encoding set in the text box.
    • Non-MIME character set   To identify a non-MIME character set, type the character encoding set in the text box.
  5. Use the Office 365 Tenant Domain tab to specify whether this remote domain is used for your cloud-based organization.
    • Use this domain for my Office 365 tenant   If the new remote domain you’re creating represents the part of your organization that is hosted on Microsoft Office 365, select this check box.

 

You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the «Remote domains» entry in the Transport Permissions topic.

You use the Set-RemoteDomain cmdlet to configure the properties of a remote domain. This section provides examples on how to configure various properties of a remote domain.

This example makes sure that no out-of-office messages are sent to the domain.

Set-RemoteDomain "RemoteDomain" -AllowedOOFType None

This example allows only external out-of-office messages.

Set-RemoteDomain "RemoteDomain" -AllowedOOFType External

This example allows external out-of-office messages and out-of-office messages set by Outlook 2003 or earlier clients or sent by Exchange 2003 or earlier servers.

Set-RemoteDomain "RemoteDomain" -AllowedOOFType ExternalLegacy

This example allows internal out-of-office messages and out-of-office messages set by Outlook 2003 or earlier clients or sent by Exchange 2003 or earlier servers.

Set-RemoteDomain "RemoteDomain" -AllowedOOFType InternalLegacy

This example allows automatic replies to the remote domain. By default, this setting is disabled.

Set-RemoteDomain -Identity Contoso -AutoReplyEnabled $true

This example allows automatic forwards to the remote domain. By default, this setting is disabled.

Set-RemoteDomain -Identity Contoso -AutoForwardEnabled $true

This example disables delivery reports to the remote domain. By default, this setting is enabled.

Set-RemoteDomain -Identity Contoso -DeliveryReportEnabled $false

This example disables non-delivery reports to the remote domain. By default, this setting is enabled.

Set-RemoteDomain -Identity Contoso -NDREnabled $false

This example disables the display of the sender’s name on messages. By default, this setting is enabled. We recommend that you leave this option enabled.

Set-RemoteDomain -Identity Contoso -DisplaySenderName $false

This example enables the line wrapping of message text and sets the column width to 76 characters.

Set-RemoteDomain -Identity Contoso -LineWrapSize 76

This example allows notification to be sent to a remote domain when a meeting request from a sender in the remote domain is forwarded to another recipient. By default, this setting is disabled.

Set-RemoteDomain -Identity Contoso -MeetingForwardNotificationEnabled $true

This example configures both the MIME and non-MIME characters sets to the Western European character set (ISO-8859-1).

Set-RemoteDomain -Identity Contoso -CharacterSet "ISO-8859-1" -NonMimeCharacterSet "ISO-8859-1"

This example specifies that Transport Neutral Encapsulation Format (TNEF) encoding is used for all messages sent to the remote domain. By default, the value for this setting is $null, and TNEF encoding is controlled by individual user settings. The TNEF settings are shown as the Exchange rich-text format options in the EMC.

Set-RemoteDomain -Identity Contoso -TNEFEnabled $true

For detailed syntax and parameter information, see Set-RemoteDomain.

 © 2010 Microsoft Corporation. All rights reserved.



Exchange проверка IMAP

Чтобы убедиться в наличии правильного подключения IMAP4 в почтовый ящик, который расположен на сервере Exchange, введите следующие команды в командной строке.

Примечание За исключением первой команды необходимо ввести знак вопроса (?) и пробел в начале каждой команды.Нажмите клавишу ВВОД после ввода каждой команды.

  1. Telnet IP-адрес почтового сервера (Exchange) 143Эта команда запускает сеанс Telnet. Если эта команда выполняется успешно, появляется следующий ответ с сервера. 
    +OK Microsoft Exchange IMAP4rev1 server version x.x.x (F.Q.D.N.) ready
  2. ? Входа в СИСТЕМУ УЧЕТНАЯ ЗАПИСЬ NT NTDOMAIN-ПСЕВДОНИМ ПАРОЛЬЭта команда запускает связь посредством входа в почтовый ящик. Если эта команда выполняется успешно, появится следующий ответ: 
    +OK LOGIN completed
  3. ? LIST «» «*»Эта команда предоставляет список доступных папок.
  4. ? Выберите Папка (где Папка — это папки почтового ящика, который требуется, например, входящие или удаленные) Эта команда выбирает соответствующий почтовый ящик. Если эта команда выполняется успешно, появится сообщение, подобное приведенному ниже, в зависимости от количества сообщений в почтовом ящике: 
    * <#> EXISTS
* <#> RECENT
* FLAGS (\Seen \Answered \Flagged \Deleted \Draft)
* OK [PERMANENTFLAGS (\Seen \Answered \Flagged \Deleted \Draft)]
* OK [UNSEEN <#>] Is the first unseen message
* OK [UIDVALIDITY 73] UIDVALIDITY value.
? OK [READ-WRITE] SELECT completed.
  5. ? ВЫБОРКА номер сообщения> Все (где номер сообщения — 1, 2, 3 и т. д.)
    ? ВЫБОРКА номер сообщения Тело (где номер сообщения — 1, 2, 3 и т. д.) Эти команды извлечь определенные сообщения. Если команда выполнена успешно, появляется сообщение, которое указано «число сообщений» ответ, похожее на следующее:

    * 1 FETCH (FLAGS ( )  INTERNALDATE "25-JUN-1998 10:57:38 -500"
RFC822.SIZE 417 ENVELOPE 9"Thu, 25 Jun 1998 10:57:33 -500" "Test"
(("Administrator" NIL "Administrator" "microsoft.com"))
(("Administrator" NIL "Administrator" "microsoft.com"))
(("Administrator" "microsoft".com")) NIL NIL NIL
"219876E11AFBD111A43F00C04F8FECCA33D4@mail2.dns.microsoft.com"))
* ? OK FETCH completed.
  6. ? ВЫХОДЭта команда регистрирует пользователя из сеанса IMAP4 на сервере Exchange. Если эта команда выполняется успешно, появится сообщение, подобное приведенному ниже: 
    ? LOGOUT
* BYE Microsoft Exchange IMAP4rev1 server version 5.5.2654.50 signing off
? OK LOGOUT completed.

    Примечание Номер версии в этом сообщении могут различаться в зависимости от установленного пакета обновления Exchange. В примере предполагается, что выполняется Exchange 5.5 в Пакет обновления 4 (SP4) установлена.

Если успешного выполнения этой процедуры любого клиента IMAP4, совместимом с запросом for Comment (RFC) 2060 – код должен быть доступ к почтовому ящику на сервере Exchange.



Exchange 2010 + Outlook

 

Возникла проблема что MS Outlook не забирает почту с Exchange.

Есть EXCH2010+локальные компы+мобильные устройства(iPhone+Android).
ситуация такая
1 на мобильные и на OWA почта приходит моментом, т.е. почта в ящик падает.
2 А вот Outlook категорически не хочет забирать ее при включенном режиме кэширования.
3 при пересоздании профиля работает нормально.

Решение, может и кривое, но решение:

Берем шаблоны групповых политик для MS Office нужной версии. Отключаем в политиках кеширование почты —

после этого ждем пока все пользаки перелогоняться, проверяем все пару дней, а потом отключаем ну и все заново.



Microsoft Exchange Server 2010: Роли сервера

Microsoft Exchange Server 2010: Серверные роли

То, как вы настраиваете серверные роли и управляете ими, сильно влияет на эффективность инфраструктуры Exchange Server.

Выдержки из книги «Exchange 2010 — A Practical Approach» издательства Red Gate Books (2009).

Джепп Весселиус (Japp Wesselius)

В Exchange Server и серверных ролях многое изменилось. До выпуска Exchange Server 2003 приходилось устанавливать все роли на одном сервере. Нельзя было выбрать функции, которые должны быть доступны. Можно было назначить сервер Exchange 2000 или Exchange 2003 в качестве так называемого «сервера переднего плана», но он работал как обычный сервер Exchange в качестве прокси протокола. На нем по-прежнему по умолчанию устанавливались база данных почтовых ящиков и база данных общих папок.

В Exchange Server 2007 была представлена концепция «серверных ролей». Exchange Server 2010 значительно расширяет эту концепцию. Exchange Server 2010 имеет следующие серверные роли, каждая из которых имеет определенную функцию.

  • Роль сервера почтовых ящиков
  • Роль сервера клиентского доступа
  • Роль транспортного сервера-концентратора
  • Роль пограничного транспортного сервера
  • Роль сервера единой системы обмена сообщениями

Можно установить эти роли серверов на отдельном оборудовании, на котором каждая машина имеет собственную роль. Также можно объединить роли на одном сервере. Например, типичная установка сервера включает роли серверов почтовых ящиков, клиентского доступа и транспортного сервера-концентратора. Средства управления всегда устанавливаются во время установки независимо от устанавливаемой роли сервера.

Однако роль пограничного транспортного сервера не может объединяться с другими ролями. Фактически, роль пограничного транспортного сервера может быть даже частью внутреннего домена, поскольку предназначена для установки в периметре сети. Есть множество причин разделения Exchange Server на несколько серверных ролей.

  • Улучшенная масштабируемость. Поскольку можно выделить один сервер для одной серверной роли, преимущества масштабируемости огромны. Можно настроить и оптимизировать конкретный сервер для одной определенной роли, что обеспечивает высокую производительность сервера.
  • Улучшенная безопасность. Можно усилить безопасность одного выделенного сервера, используя мастер настройки безопасности. Поскольку на определенном сервере используется только одна серверная роль, все другие функции и порты отключаются, что обеспечивает лучшую защиту системы.
  • Упрощенное развертывание и администрирование. Выделенный сервер более прост в настройке, защите и администрировании.

Ниже подробно рассматриваются все серверные роли.

Роль сервера почтовых ящиков

Роль сервера почтовых ящиков — сердце среды Exchange Server 2010. В ней устанавливаются базы данных почтовых ящиков и общих папок. Единственная цель сервера почтовых ящиков — размещение почтовых ящиков и общих папок, и ничего более.

В предыдущих версиях Exchange Server, включая Exchange Server 2007, клиенты Outlook использовали MAPI с подключением напрямую к роли сервера почтовых ящиков. Это больше не так в Exchange Server 2010. Теперь клиенты MAPI подключаются к службе под названием «Клиентский доступ RPC», выполняющейся на сервере клиентского доступа.

Роль сервера почтовых ящиков не выполняет маршрутизацию никаких сообщений. Она только сохраняет сообщения в почтовых ящиках. Роль транспортного сервера-концентратора обрабатывает всею маршрутизацию сообщений, даже между почтовыми ящиками на одном сервере или в одной базе данных почтовых ящиков. Сервер клиентского доступа всегда требуется для доступа к почтовым ящикам. Для реализации модели управления доступом на основе ролей (RBAC) требуются IIS в роли сервера почтовых ящиков, даже если клиент обращается к серверу почтовых ящиков напрямую.

Группы хранения больше не существуют в Exchange Server 2010, но почтовые ящики по-прежнему хранятся в базах данных, как и в Exchange Server 2007. Как и в предыдущих версиях Exchange Server, по-прежнему используется расширенный обработчик хранилищ (ESE), хотя в базу данных и в схему баз данных внесены серьезные изменения. По умолчанию первая база данных на сервере устанавливается в каталог: C:\Program Files\ Microsoft\Exchange Server\V14\Mailbox\Mailbox Database <<identifier>>

<<identifier>> — это уникальное число для обеспечения уникальности имени базы данных почтовых ящиков в организации сервера Exchange.

С точки зрения производительности и восстановления рекомендуется размещать базу данных и прилагаемые файлы журналов на выделенном диске. Этот диск может размещаться в сети хранения данных, подключенной по оптоволоконному каналу (SAN), iSCSI SAN или в решении системы хранения с прямым подключением (DAS). Целью проектирования было ограничение числа дисковых операций ввода-вывода на уровне, на котором можно установить базу данных и файлы журнала на диске SATA размером 1 ТБ, но это возможно только при настройке копий базы данных и наличии не менее двух копий базы данных почтовых ящиков, чтобы избежать появления единственной точки сбоя.

Роль сервера клиентского доступа

Роль сервера клиентского доступа предоставляет все доступные протоколы доступа к почтовым ящикам. В Exchange Server 2003 корпорация Майкрософт представила концепцию серверов «переднего плана» и «внутренних» серверов. Роль сервера клиентского доступа сравнима с сервером переднего плана Exchange Server 2003.

Все клиенты подключаются к серверу клиентского доступа. После проверки подлинности запросы передаются через прокси соответствующему серверу почтовых ящиков. Связь клиента и сервера клиентского доступа осуществляется по обычным протоколам (HTTP, IMAP4, POP3 и MAPI). Связь сервера клиентского доступа и сервера почтовых ящиков осуществляется через удаленные вызовы процедур (RPC).

Сервер клиентского доступа Exchange Server 2010 предоставляет следующие функции.

  • HTTP для Outlook Web App
  • Мобильный Outlook (ранее называвшийся RPC/HTTP) для Outlook 2003, Outlook 2007 и Outlook 2010
  • ActiveSync для карманных ПК
  • Протоколы Интернета POP3 и IMAP4
  • MAPI на среднем уровне (MoMT)
  • Служба доступности, автообнаружение и веб-службы Exchange: предоставляются для клиентов Outlook 2007 и обеспечивают сведения о доступности, автоматическую настройку клиентов Outlook 2007 и Outlook 2010, загрузки автономной адресной книги и функцию отсутствия на месте.

Сервер клиентского доступа не предоставляет службы SMTP. Транспортный сервер-концентратор обрабатывает все службы SMTP. Для каждого сервера почтовых ящиков на сайте Active Directory требуется по крайней мере один сервер клиентского доступа, а также быстрое соединение между сервером клиентского доступа и сервером почтовых ящиков. Серверу клиентского доступа также требуется быстрое соединение с сервером глобального каталога.

Сервер клиентского доступа должен быть развернут во внутренней сети, а не в периметре сети. Для доступа к серверу клиентского доступа из Интернета необходимо установить сервер Microsoft Internet Security and Acceleration (ISA) Server в периметре сети. Затем требуется «опубликовать» все необходимые для Интернета службы Exchange на этом сервере ISA Server.

Роль транспортного сервера-концентратора

Роль транспортного сервера-концентратора ответственна за маршрутизацию сообщений не только между Интернетом и инфраструктурой Exchange, но также и между серверами Exchange. Сообщения всегда маршрутизируются с помощью роли транспортного сервера-концентратора, даже если почтовые ящики источника и назначения находятся в одной базе данных почтовых ящиков. Например, транспортный сервер-концентратор маршрутизирует сообщения следующим образом.

Шаг 1. Кто-нибудь отправляет сообщение транспортному серверу-концентратору.

Шаг 2. Если отправитель и получатель находятся на одном сервере, сообщение пересылается обратно.

Шаг 3. Если получатель находится на другом сервере почтовых ящиков, сообщение направляется на соответствующий транспортный сервер-концентратор.

Шаг 4. Затем второй транспортный сервер-концентратор доставляет сообщение на сервер почтовых ящиков получателя.

Обеспечение соответствия — основная причина маршрутизации всех сообщений через транспортный сервер-концентратор. Можно отслеживать все сообщения в организации Exchange и принимать необходимые меры для соблюдения правовых требований, закона об отчетности в области медицинского страхования (HIPAA), закона Сарбэйнса – Оксли и других норм. На транспортном сервере-концентраторе для целей соответствия можно настроить следующие агенты.

  • Агенты правила транспорта. К сообщениям можно применять действия в соответствии с условиями или фильтрами правил. Правила можно применить к внутренним сообщениям, внешним сообщениям или обоим типам сообщений.
  • Агенты ведения журналов. Эти агенты сохраняют копии все сообщений, отправленных или полученных определенным получателем.

Поскольку сервер почтовых ящиков не доставляет сообщения, для каждого сервера почтовых ящиков на сайте Active Directory требуется транспортный сервер-концентратор. Транспортному серверу-концентратору также необходимо быстрое подключение к серверу глобального каталога для запросов Active Directory. Этот сервер глобального каталога должен находиться в том же сайте Active Directory, в котором находится транспортный сервер-концентратор.

Если сообщение предназначается внешнему получателю, оно отправляется с транспортного сервера-концентратора через Интернет. Это может осуществляться через пограничный транспортный сервер Exchange Server 2010 в периметре сети, но транспортный сервер-концентратор также доставляет сообщения напрямую через Интернет.

Транспортный сервер-концентратор также можно настроить на осуществление функций защиты от вирусов и нежелательной почты. Службы защиты от нежелательной почты по умолчанию отключены на транспортном сервере-концентраторе, поскольку эта служба предназначена для запуска на пограничном транспортном сервере в периметре сети. Корпорация Майкрософт предоставляет с каждым транспортным сервером-концентратором сценарий для включения служб защиты от нежелательной почты.

Можно использовать возможности защиты от вирусов Microsoft Forefront для Exchange. Их использование на транспортном сервере-концентраторе обеспечивает проверку входящего и исходящего SMTP-трафика. На сервере почтовых ящиков будет проверяться содержимое базы данных почтовых ящиков, что обеспечивает два уровня защиты.

Роль пограничного транспортного сервера

Роль пограничного транспортного сервера была представлена в Exchange Server 2007 и обеспечивает дополнительный уровень гигиены сообщений. Обычно она устанавливается как шлюз SMTP в периметре сети. Внешние сообщения сначала доставляются роли пограничного транспортного сервера. После прохождения фильтров защиты от вирусов и нежелательной почты эти сообщения перенаправляются транспортному серверу-концентратору во внутренней сети.

Пограничный транспортный сервер также может предоставлять следующие функции.

  • Правила пограничного транспортного сервера. Эти правила контролируют поток сообщений, отправляемых или получаемых через Интернет, если эти сообщения соответствуют определенным условиям.
  • Перезапись адресов. Эта служба изменяет SMTP-адрес сообщений, отправляемых или получаемых через Интернет. Это может быть полезным для скрытия внутренних доменов.

Пограничный транспортный сервер устанавливается в периметре сети. Он может быть членом внутренней службы Active Directory или организации Exchange Server 2010. Пограничный транспортный сервер использует службы Active Directory облегченного доступа к каталогам (AD LDS) для хранения всей информации.

В ранних версиях Windows эта служба называлась режимом Active Directory Application Mode (ADAM). Службы AD LDS сохраняют основные сведения об инфраструктуре Exchange, такие как получатели и транспортный сервер-концентратор, которому пограничный транспортный сервер отправляет сообщения. Они используют функцию синхронизации под названием EdgeSync для обновления базы данных AD LDS. Это обеспечивает передачу информации с транспортного сервера-концентратора пограничному транспортному серверу с регулярными интервалами.

Роль сервера единой системы обмена сообщениями

Роль сервера единой системы обмена сообщениями Exchange Server 2010 объединяет базу данных почтовых ящиков, голосовые сообщения и сообщения электронной почты в одном хранилище. Роль сервера единой системы обмена сообщениями предоставляет доступ ко всем сообщениям в почтовом ящике по телефону или с помощью компьютера. Можно использовать IP-систему или «классическую» аналоговую телефонную систему АТС, хотя в последнем случае для подключения двух систем требуется специальный шлюз IP единой системы обмена сообщениями.

Роль сервера единой системы обмена сообщениями предоставляет следующие функции.

  • Ответы на вызовы. Эта функция действует как автоответчик. Если невозможно ответить на вызов, записанное персональное сообщение отправляется в почтовый ящик получателя как файл MP3.
  • Абонентский доступ. Эта функция иногда называется «голосовым доступом к Outlook». Абонентский доступ позволяет пользователям прослушивать сообщения голосовой почты в своих почтовых ящиках, используя обычную телефонную линию. Также предоставляется доступ к элементам почтовых ящиков, таким как сообщения и элементы календаря, также можно изменять график встреч.
  • Автосекретарь. Эта функция позволяет создавать пользовательское меню в единой системе обмена сообщениями, используя голосовые инструкции. Вызывающий абонент может использовать клавиатуру телефона или голосовые команды для перемещения в меню.

Служба единой системы обмена сообщениями, установленная в роли сервера единой системы обмена сообщениями, тесно взаимодействует с подсистемой работы с речью Microsoft Exchange. Подсистема работы с речью предоставляет двухтональный многочастотный набор (DTMF), также называемый тональным набором, автоматическое распознавание речи и функцию преобразования текста в речь, ответственную за чтение элементов почтового ящика и голосовых меню.

Роль сервера единой системы обмена сообщениями должна быть установлена на сайте Active Directory вместе с транспортным сервером-концентратором. Последний сервер ответственен за маршрутизацию сообщений серверам почтовых ящиков. Также требуется быстрое соединение с сервером глобального каталога. Если возможно, также следует установить роль сервера почтовых ящиков максимально близко к роли сервера единой системы обмена сообщениями, желательно в пределах одного сайта с достаточным сетевым подключением.

Функции обеспечения высокой доступности, управления и обеспечения соответствия требованиям делают Exchange Server 2010 привлекательным решением. Фактически, новые функции Exchange Server 2010, как правило, обеспечивают снижение сложности, что всегда предпочтительно.

 

(c)http://technet.microsoft.com/ru-ru/magazine/hh536214.aspx



Перенос базы Exchange

Вообщем ситуация такова: хранилище exchane больше 200гб, место на диске заканчивается с умопомрачительной быстротой, «резать» пока возможности нет, т.к. не знаешь сколько это займет. вариант выживания один — перенос базы на новый больший диск, благо все это работает на связке ESX vSphere + OpenFiler, т.е. минус перезагрузка для подключения дисков.

Цель этой заметки — примерно обрисовать время по переносу для «будущих поколений».
Итак, вся процедура проделывается по такой инструкции(полный вариант инструкиции на http://support.microsoft.com/kb/821915):
1. Запустите диспетчер Exchange System Manager.
2. Откройте группу администраторов, содержащую базу данных, которую необходимо изменить.
3. В списке Storage Group щелкните правой кнопкой мыши хранилище почтовых ящиков или общих папок, которое необходимо изменить, и выберите Properties.
4. Откройте вкладку Database.
5. Нажмите кнопку Browse рядом с именем базы данных, которую необходимо изменить, после чего укажите новый диск или папку для файлов.

Примечания.
* При переносе баз данных можно переместить базу данных Exchange (файл .edb) или потоковую базу данных Exchange Streaming (файл .stm), а также обе эти базы.
* Если базы данных по-прежнему присоединены, появится следующее сообщение:
You are about to perform the following operation(s):
— change Exchange database location
To perform the requested operation(s), the store must be temporarily dismounted which will make it inaccessible to any user.

Do you want to continue?
Нажмите кнопку Да, чтобы автоматически отключить базу данных и перенести ее в другое место.
6. Завершив перенос баз данных, подключите их вручную.

Файлы журналов и базы данных можно перемещать в любую созданную папку. Перемещая файлы журналов и баз данных, для сохранения целостности данных можно создать файловую структуру Exchsrvr\Mdbdata, однако делать это не обязательно.

В сухом остатке получаем перенос базы на каналах в 1Гб занял 5 часов….все прошло пучком, базы целы, пользователи довольны.:)