Собственно, у меня два замечания к указанной статье:
1. Подача в общем-то низкоуровневых исправлений без малейшего объяснения побочных эффектов и каких-либо ссылок на документацию. Для автора такого уровня компетенции это выглядит странно.
2. Решения задачи можно добиться и менее радикальными методами, чем изменение опций ядра Windows.
Для начала немного лирики.
Работа в терминальной многопользовательской среде, безусловно, имеет свою специфику. К сожалению, далеко не все приложения эту специфику учитывают. Здесь и использование ресурсов сверх необходимости - режим "я дома один" см. 1С:Предприятие 7.7 и ВК Terminal Sleep, и непродуманные визуальные эффекты - та же заставка 1С:Преприятие 7.7 и градиентная заливка 1С:Предприятие 8.2 Турбо-милк.
С другой стороны, не всем приложениям учет такой специфики требуется - для них вполне достаточно стандарных требований к разработке Windows приложений. К числу последних я отнесу и обсуждаемый Конфигуратор.
Теперь про DFSS.
Возьмем гипотетический пример. Имеем терминальный сервер с 4 процессорами, имеющими производительность 1000 попугаев каждый. Итого 4000 попугаев. Запускать на серверах мы будем только программы 1С. Поскольку 1С однопоточное приложение (строго говоря это не так, но на практике влиение остальных потоков малозначительно), то каждое 1С приложение может использовать только один процессор и максимально сможет работать со скоростью 1000 попугаев.
На терминал заходит мега-разработчик и открывает Конфигуратор. При запуске Конфигуратор получит свои 1000 попугаев. Все нормально. Закроем приложение. И запустим одновременно 4 Конфигуратора. Что произойдет? А ничего, все получат свои 1000 попугаев. Опять все закрываем.
Теперь в терминал зашел пользователь и запустил в Предприятии отчет с большой постобработкой результата встроенным языком. ОК. Получит 1000 попугаев. Пока все как обычно.
А если запустить формировать отчет и открывать Конфигураторы? Выделить 5000 попугаев операционка уже не сможет, поэтому выдаст всем поровну - по 800 попугаев каждому. Это стандарное поведение системы, опять же ничего необычного. Но все ли здесь нормально? Нет, не все. Получается, что чем больше пользователь запустит ресурсоемких операций тем больше он будет мешать другим пользователям работать.
Для исправления ситуации Microsoft начиная с Windows Server 2008 R2 на уровне ядра выделила еще один разрез для распределения ресурсов - сессию. Соответственно, появился механизм DFSS - Dynamic Fair Share Scheduling (вольн. -Динамическое честное распределение ресурсов).
Что произойдет при включенном DFSS в третьем сценарии? Система отработает уже по другому - сначала поделит ресурсы пополам (у нас две сессии), т.е. каждый пользователь получит 2000 попугаев. Теперь формирование отчета получит 1000 попугаев, а каждый конфигуратор 500. Все по честному (fair) - у каждого пользователя одинаковое количество ресурсов, а дальше уже его право распоряжатся выделенными ему ресурсами как угодно (можно даже запускать 1С:Предприятие 7.7 без ВК Terminal Sleep). Теперь никакая нагрузка пользователя не повлияет на работу других пользователей.
Как это выглядит в документации, можно посмотреть здесь: https://technet.microsoft.com/en-us/library/dd560667(v=ws.10).aspx#BKMK_4
Windows Server 2008 использовал DFSS только для регулирования ресурсами процессора, но идея оказалась столь хороша, что в Windows Server 2012 DFSS рулит еще и дисковыми операциями и полосой пропускания сети.
Замечу также, что DFSS включается по умолчанию при установке роли Remote Desktop Services и явлется опцией ядра - т.о. его изменение требует перезагрузки ОС.
Решение проблемы.
Вернемся в медленному запуску конфигуратора. Можем ли мы как-то ускорить его запуск без отключения DFSS? Конечно, можем! Вспомним, что DFSS для управления использует сессии пользователей, т.е. если мы можем выделить мега-разработчиков из сонма пользователей, то, возможно, для них получится более "честно" настроить политику выделения ресурсов. Ну а если не можем (да у нас каждый второй запускает конфигуратор), то, возможно, получится выделить процесс конфигуратора из всех остальных.
Для решения задачи используем WSRM - Windows System Resource Manager https://technet.microsoft.com/en-us/library/cc755056.aspx (Q&A на русском: https://technet.microsoft.com/ru-ru/windowsserver/bb405954.aspx )
В оснастке WSRM есть раздел "Process Matching Criteria". При создании нового критерия отбора процессов можно указать конкретное приложение (можно даже просто имя файла 1cv8.exe) и пользователей (группы пользователей) входящих в критерий. В разделе "Resource Allocation Plolicies" можно установить, что для определенного критерия (например 1cv8.exe и i.petrov) установить выделение 50% процессорной мощности системы. И мы решили проблему медленного запуска конфигуратора у пользователя i.petrov. Правда под критерий попадает еще и толстый клиент, но это скорее бонус для i.petrov.
К сожалению, в Windows Server 2012 WSRM признана устаревшей, и заменена Hyper-V имеющий схожую функциональность. https://technet.microsoft.com/library/hh831568.aspx Здесь Microsoft лукавит - Hyper-V не занимается регулированием процессов, но оставим это на совести Microsoft. Возможно, эта функция будет полезна в Windows Server Next, гда появится поддержка Docker, но это будет уже завтра. http://news.microsoft.com/2014/10/15/dockerpr/
Но и здесь есть выход. Вспомним, что DFSS рулит еще и дисковыми ресурсами, а конфигуратор при открытии как раз и занимается усиленной работой с диском. Т.е. вполне достаточно установить в "0" TSFairShare (п. 2 в статье). Кстати появится еще один полезный эффект - повысится скорость работы с локальными файловыми базами 1С:Предприятия 8, и с базами 1С:Предприятия 7.7 (ну вдруг!) как для файлового, так и для SQL-варианта.
Теперь подойдем с другой стороны. Есть ли необходимость изменения опций ядра для запуска Конфигуратора 1С?
Скорее всего, нет. Сценарий, когда есть терминальный сервер или терминальная ферма, на которой разработчик будет работать наравне с пользователями, нарушает как минимум принцип разделения рабочей и тестовой среды. Если же запуск конфигуратора является эпизодическим (например, для удаленного внесения изменений), то такое решение носит избыточный характер, см. "от головной боли помогает топор". Особенно на фоне выгоды в 30 секунд.
Окончание.
Вернемся обратно к озвученным мной замечаниям:
1. Необходимо добавить ссылки:
1.1. про DFSS https://technet.microsoft.com/en-us/library/dd560667(v=ws.10).aspx#BKMK_4
1.2. Фрагмент "(gwmi win32_terminalservicesetting -N "root\cimv2\terminalservices").enabledfss" заменить на полный формат
Get-WmiObject -Class win32_terminalservicesetting -Namespace root\cimv2\terminalservices | Format-List EnableDFSS,EnableDiskFSS,EnableNetworkFSS
и дать ссылку на https://msdn.microsoft.com/en-us/library/aa383640(v=vs.85).aspx
1.3. Дополнить п.1 возможностью устанавливать значение групповой политикой: Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connection\Turn off Fair Share CPU Scheduling https://technet.microsoft.com/ru-ru/library/ee791922(v=ws.10).aspx
2. Достаточно выполнить только п.2 из статьи.
