Аккаунты с выключенным наследованием прав доступа и Exchange 2013/Lync 2013

 

В процессе внедрения Exchange или Lync можно столкнуться с акантами, для которых не работает или работает странно часть функционала Exchange 2013 или невозможность активировать аккаунт для работы в Lync 2013. На самом деле эти проблемы могут возникать и в более ранних версиях этих продуктов.

Расследование показывает, что эти аккаунты существуют давно и имеют или имели когда-то более широкие права чем другие. Самый распространенный случай – выданные права администраторов домена.

Собственно внедрение этих продуктов хороший повод к проведению аудита прав, лишения их у тех кому это не нужно в принципе, а тем, кому это все-таки нужно следует перейти на двуаккаунтную работу. Один аккаунт будет иметь рядовые права в домене и он же будет использоваться в Exchange/Lync, ну а второй будет использоваться для целей администрирования.

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

NDR при отправке сообщений от имени группы рассылки в Exchange 2013

Практика показывает, что Exchange “не любит” отсылать NDR сообщения на группу. В общем-то, зачастую, это и не нужно. Но есть ситуация, когда пользователь отправляет сообщение от имени группы и, конечно же, хочет знать о случаях когда оно не дошло.

Для того, чтобы это заработало нужно сделать несколько пунктов:

1. Переключить отправку NDR от отправителя к менеджеру (владельцу)
Get-DistributionGroup Group1| Set-DistributionGroup -ReportToManagerEnabled $true -ReportToOriginatorEnabled $false

2. Включить нужных пользователей в список owners (владельцев) и их же в список Send As. При этом, если вдруг вы пропишете их еще и в список Send on Behalf, то работать не будет

Смена устаревшего пароля с помощью OWA для Exchange 2013

 

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

Ранее, в Exchange 2007 & Exchange 2010 были способы, которые помогали в настройке этой функции. Они требовали некоторых манипуляций с реестром. Как оказалось, в Exchange 2013 старые способы уже не работают.

Так что же делать, если нужно пароль устарел или включена функция поменять при следующем входе?

Все достаточно просто. Нужно зайти на каждый из серверов с ролью CAS, там запустить IIS Manager, в нем перейти на Default Web Site, потом на виртуальный каталог owa, затем выбрать Authentication и для Basic Authentication прописать в поле Default domain значение “\” и нажать OK.

После этого нужно запустить команду iisreset /noforce

Это справедливо для Exchange 2013 и Windows Server 2012.

Мне этого оказалось достаточно, хотя советовали еще и уменьшить минимальный срок действия пароля с одного дня до нуля.

Exchange 2013 ошибка smtp 421 4.3.2 Service Not Available

В процессе настройки вылезла интересная проблема, время от времени smtp сервис перестает отвечать на запросы и вместо этого начинает выдавать ошибку
421 4.3.2 Service Not Available

Если перезапустить сервис транспорта (Micorosoft Exchange Transport), то на какое-то время проблема исчезает, но, затем, снова появляется. Метод лежащий на поверхности – поставить в шедуллер маленький скриптик, который будет раз в несколько часов передергивать сервис конечно рабочий, но это классический “костыль” :-)

Оказалось, что дело в созданных Receive Connector, точнее в их конфликте с базовыми. Для устранения проблемы нужно переписать или запомнить параметры созданных вами соединителей, затем удалить их и создать новые. При создании нужно в переключателе “Role” выбирать “Frontend Transport”, а не “HUB Transport”, который выбран по умолчанию.

Это то решение, которое помогло мне и даже в процессе поиска показалось самым логичным. Кроме того, встречались советы, которые якобы помогли людям:

• Отключить MailWare filter: Set-MalwareFilteringServer -BypassFiltering $true
• Прописать в файл hosts ipv4 адреса серверов Exchange как в FQDN так и просто имя сервера

Эти советы я даже и не проверял, но если вам не поможет способ с изменением роли соединителя, то можете попробовать.