MVV

Exchange, если нет разрешения на применение команды, пишет именно то, что команда не найдена, а не то, что нет разрешения.
Поэтому проверьте наличие нужной для управления соединителем роли у пользователя, под которым запускаетте EMS. Чтобы сильно не заморачиваться, просто используйте пользователя с членством в ролевой группе Organization Management (ролевые группы представлены как одноименные универсальные группы в AD, можете проверить безо всякого Exchange члество пользователя там).

PS Я предполагаю, что у вас разрешения Exchange установлены по умолчанию и split permissions не используется. Если это не так - придется рыть конкретно, что и как у вас там настроено, варианты возможны весьма разнообразные.

В Exchange Management Shell (который Powershell) командой:

Set-SendConnector -Identity <SendConnectorIdParameter> -FQDN <fqdn>

SendConnectorIdParameter - имя соединителя, через который идет отправка почты в Интернет
fqdn - имя, которое разрешается во внешний белый IP сервера, желательно чтобы IP-адрес разрешался в это имя (этот вопрос решается с провадером: нужно изменить или добавить в зоне обратного разрешения запись PTR).

Иной способ существует: написать скрипт, проходящий по всем письмам в п/я и удалить из них вложения. Комндлета для EMS для этого нет (AFAIK), но в PowerShell для этого можно использовать EWS Managed API.

Только вот написать скрипт, да ещё чтобы он работал без ошибок и ничего не попортил в процессе отладки - это не так просто. Да и разрешения нужно ему дать (стандартных разрешений админинистратора не хватит). Так что лучше IMHO этим не заморачиваться, а для повышения радивости пользователей поставить им квоты на п/я: пусть чистят сами.

Для получения ответа на столь обще поставленные вопросы имеет смысл сначала прочесть документацию произовдителя.
В целом, вы понимаете правильно: подавляющая часть конфигурации Exchange хранится в AD, а потому резервное копирование сервера Exchange состоит, в основном, из резервного копирования данных (БД), а восстановление - в установке сервера Exchange в режиме восстановления и восстановлении БД. Но может потребоваться сохранение/восстановление нестандартных настроек служб (если есть), плюс, что-то надо делать с сертификатами: либо тоже сохранять/восстанавливать, либо перевыпускать после восстановления. Подробности см. в документации.
Для резервного копирования БД Exchange вполне достаточно встроенного Windows Server Backup (описано в документации). Сторонние программы предоставляют дополнительные удобные средства для управления резервными копиями, однако стоят денег. Так что, нужны они вам, или нет -разбирайтесь сами по месту.
И напоследок - имейте ввиду, что Exchange сильно зависит от AD, поэтому о сохраненности ее данных надо обязательно позаботиться.

1. Чтобы Exchange Server принимал почту для другого домена, этот домен в нем должен быть прописан в Обслуживаемых доменах с типом "Внутренняя ретрансляция". А для фактической отправки почты на другой домен нужно создать соединитель отправки для этого домена с назначением (smarthost) на сервер, фактически обслуживающий этот домен. Сервер на том конце может быть совершенно любым сервером SMTP.
2. Адреса для п/я в Exchange настраиваются политиками адресов: в политике должен быть прописан первичный домен для адреса SMTP (используется и для отправки и для приема) и может быть несколько вторичных доменов. На той стороне, где нужно поменять адреса, просто добавьте в политику нужный домен с нужным типом. Кстати, если политика поменяет первичнй адрес п/я, то его бывший первичный адрес останется в качестве вторичного, так что, если новым пользователям не нужно добавлять адреса из старого домена, то в политике можно просто заменить первичный домен на новый, не оставляя старый вторичным.
3. Чтобы письма с Exchange с адресом его обслуживаемого домена могли отправляться на другой сервер SMTP (в том числе - в Exchange в другом лесу), нужно сменить тип этого домена с полномочного на внутреннюю ретрансляциию и создать соединитель отправки аналогично п.1
4. Вам наверняка потребуется синхронизировать адресные книги обоих Exchange. Раньше для этого можно было использовать бесплатный упрощенный вариант Microsoft Identity Integration Server (названия у него были разные, но суть одна: синхронизация AD между разными лесами, так чтобы пользователи с п/я из одного леса отображались как контакты в другом). Остался ли он сейчас - не интересовался. Но, в принципе, это может делаться и скриптом.
5. Вариантов совместного использования Exchange много разных (например, можно сделать общие календари). Но тут я их рассматривать не буду - вы все равно, скорее всего, захотите все это поскорее мигрировать в один лес. Но если интересно - ищите книги/документацию по Exchange 2007: эта функция (называется "федерация") в современном виде появилась там, и лучшие описания относятся именно к этой версии. С тех пор мало что поменялось, потому что MS пошла в облака.
6. При миграции есть возможность заводить п/я в одном лесу для пользователей из другого, доверенного леса (называется это Linked Mailbox, как по-русски - точно не помню). Для этого, кстати,в Exchange есть скрипт (его использовали для подготовки миграции с ADMT или ему подобными).