Как поломать Autodiscover безобидной настройкой


Сегодня с коллегой разбирались с некой проблемой на Exchange Server 2013 и попутно увидели в логах предупреждение за номером Event ID:2002 «The number of outstanding requests for guard TargetBackend («») has exceeded the max limit 150. Current request will be rejected.» На фронтендах добавили в web.config строчку <add key=”HttpProxy.ConcurrencyGuards.TargetBackendLimit” value=”2000″ />. Предупреждение ушло. Когда разобрались с основной проблемой, эта настройка осталась в конфиге.

Через некоторое время пользователи пожаловались, что не работает почта (клиенты) снаружи из Интернет. Проверка на https://testconnectivity.microsoft.com показала, что сломался autodiscover. Снаружи. Внутри работает. Перебрали всю цепочку — все в норме, но проблема есть. Коллега подключился из браузера по линку /Microsoft-Server-ActiveSync/, и среди прочей информации мы с удивлением обнаружили  выше упомянутую строчку подсвеченную красным! Убрали из конфигов — autodiscover снаружи ожил.

Отличие Autodiscover внутри и снаружи — внутри аутентификация Windows, снаружи — Basic. Как это все связано непонятно.

Вот такая забавная ситуация. Если будете менять стандартные конфиги, будьте готовы, что разные сервисы могут отнестись к этому по-разному.

Реклама

Новый атрибут ArgumentCompletions в PowerShell Core 6.0


На днях добавил новый атрибут ArgumentCompletions в PowerShell Core 6.0.

Когда он полезен? Хорошим примером служит параметер -Format командлета Get-Date , который теперь его использует.

Этот параметер может принимать стандартные значения  FileDate,  FileDateUniversal,  FileDateTime,  FileDateTimeUniversal, а также форматные строки вида «yyyyMMdd». Чтобы реализовать автоподстановку стандартных значений по Tab (tab completion или IntelliSense), применить атрибут ValidateSet не представляется возможным: он запретит форматные строки.

Единственным вариантом в версии 5 было — реализовать и зарегистрировать свой обработчик на основе IArgumentComplete. Но это достаточно громоздкое решение.

Теперь вы можете сделать так:

[parameter]
[ArgumentCompletions("FileDate", "FileDateUniversal", "ileDateTime", "FileDateTimeUniversal" )]
<span 				data-mce-type="bookmark" 				id="mce_SELREST_start" 				data-mce-style="overflow:hidden;line-height:0" 				style="overflow:hidden;line-height:0" 			></span>Format

Теперь если вы наберете Get-Date -Format и нажмете Tab, то заработает подстановка стандартных значений.
Вы сможете это попробовать уже в Beta.8 через несколько дней и это будет работать в ваших скриптах и скопилированных командлетах в PowerShell Core 6.0 RTM.

Подсказка по установке Exchange


Оказывается Exchange при установке хранит в папке ExchangeSetupLogs не только логи, но и некоторые рабочие файлы. Если предыдущаая установка имела проблемы или завершилась с ошибкой, то рекомендуется переименовать папку ExchangeSetupLogs перед очередным запуском setup.exe.

Вышли .NET Core 2.0 and .NET Standard 2.0


Стали доступны финальные версии .NET Core 2.0 and .NET Standard 2.0. Следом вышло обновление для Visual Studio 15.3, которое делает доступным использование NET Core 2.0.

Событие достаточно значимое. Стандартизация API вообще дело полезное, а тут глобальное обновление — заявлен скачок с 16к до 32к поддерживаемых интерфейсов от версии 1.6 до 2.0. Как видно за последний год проделана огромная работа. Теперь мы имеем ощутимо мощную плаформу для мультиплатформенной разработки.

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

Другой аспект в том, что .Net Standard 2.0 это пока ~60% от интерфейсов .Net Framework. И мы уже ожидаем .Net Standard 2.1. Как развитие стандарта, так и его реализация это открытые проекты, и любой может принять в них участие на GitHub.

В проекте PowerShell Core мы уже перешли на .Net Core 2.0 RTM — вы можете скачать и установить PowerShell Core 6.0 Beta.6. За последние месяцы мы вычистили множество вынужденных «затычек» и теперь непосредственно используем .Net Core 2.0. Тем не менее из-за отсутствия поддержки некоторых интерфейсов в .Net Core 2.0, мы всё еще имеем заблокированные возможности (что работает в Windows PowerShell и не работает в PowerShell Core) и все возможные «затычки». Работа в этом направлении продолжается.

 

PowerShell Core 6.0 Beta.4


Вы уже можете скачать и протестировать PowerShell Core 6.0 Beta.4!

Из особо приятного — улучшена поддержка модулей Windows PowerShell. Если ещё в Beta.3 половина модулей вообще не загружалась, то сейчас около 80% модулей загружаются успешно — 96 из 113. Ждем исправления бага в .Net Core, что позволит нам загружать модули PS1XML. Первоисточник https://github.com/PowerShell/PowerShell/issues/4062.

Особо надо отметить, что теперь вы можете загружать модули Exchange и Sharepoint! Я уже попробовал их в работе — класс!

Также надо отметить, что оптимизирована работа консоли — теперь она работает быстрее за счет уменьшения количества выводимой служебной информации (esc-последовательностей).

Была добавлена конструкция для указания Unicode-символов `u{unicode-код}. Это работает не только в строковых константах, но и в именах (переменных, функций и т.п.). Первоисточник https://github.com/PowerShell/PowerShell/pull/3958.

 

Task Scheduler и gMSA


Решил привести в порядок запускаемые по расписанию задачи. Для консолидации таких задач существует продукт SCOR. Microsoft прекратила его развитие, хотя не так давно переписала номер версии на 2016. Но история не об этом. Читать далее

PowerShell 6 -$env:PSModulePath


PowerShell 6.0 изначально разрабатывается как мультиплатформенный и портированный на Unix системы.

Windows и Unix системы изначально различаются в некоторых вещах. Например, по умолчанию Unix системы практически везде чувствительны к регистру, а Windows нет.

Это касается и переменных окружения. Если в Windows мы можем написать имя переменной окружения в любой комбинации больших и маленьких букв, то на Unix системе поиск переменной окружения будет выполняться с учётом регистра букв. Если мы хотим, чтобы скрипт работал без изменений на обеих плаформах, то используемые имена переменных окружения должны быть в точности одинаковыми и на Windows, и на Unix.

В частности PowerShell использует переменную окружения PSModulePath для поиска модулей. После обсуждения разработчики PowerShell приняли решение, что эта переменная окружения на обеих платформах должна писаться в форме — PSModulePath.