Автозапуск клиента Lync 2013


Продолжаем облегчать себе администрирование при помощи групповых политик.

После успешного проекта по внедрению Lync в организации может возникнуть задача- запускать клиента автоматически, чтобы пользователь мог воспользоваться всеми благами совместной работы.

Проблема здесь в том, что если пользователь, скажем получил новый ПК, и ни разу не запускал клиента, усердно работая только в желтой программе с 9 до 18, то клиент и не запустится, хотя настройка по умолчанию автозапуска вроде бы есть. Давайте посмотрим, как улучшить ситуацию для клиентов 2010 и 2013, скажем, для 5000 пользователей:

Снимок

 

 

Настройка Lync 2010

Расположение ключа реестра HKCU\Software\Microsoft\Communicator
Имя ключа реестра AutoRunWhenLogonToWindows
Тип ключа реестра REG_DWORD
Значение ключа реестра 0 – клиент Lync не запустится автоматически, 1 – Lync клиент запустится

Настройка Lync 2013

Расположение ключа реестра HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Имя ключа реестра Lync
Тип ключа реестра REG_SZ
Значение ключа реестра “C:\Program Files (x86)\Microsoft Office\Office15\lync.exe” /fromrunkey
Примечание Эта настройка пути по умолчанию- если Вы ее изменили, то внесите соотв. изменение и здесь. Также здесь же можно отключить автозапуск.

regedit

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

В это поможет параметр

Software\Microsoft\Office\15.0\Lync\AutoOpenMainWindowWhenStartup с типом dword и значением 00000000.

Advertisements

Как бороться с нехваткой места на диске Exchange 2013?


Один из способов- не хранить журналы логов транспорта, если, конечно это позволяет “политика” 🙂

Ограничение в 7 дней вполне подойдет для практики реальной жизни.

Get-TransportService SVEX01 |Set-TransportService -ConnectivityLogMaxDirectorySize 500MB
Get-TransportService SVEX01 |Set-TransportService -MessageTrackingLogMaxDirectorySize 500MB
Get-TransportService SVEX01 |Set-TransportService -IrmLogMaxAge 7.00:00:00
Get-TransportService SVEX01 |Set-TransportService -ServerStatisticsLogMaxAge 7.00:00:00
Get-TransportService SVEX01 |Set-TransportService -ActiveUserStatisticsLogMaxAge 7.00:00:00
Get-TransportService SVEX01 |Set-TransportService -MessageTrackingLogMaxAge 7.00:00:00
Get-TransportService SVEX01 |Set-TransportService -TransportSyncHubHealthLogMaxAge 7.00:00:00
Get-TransportService SVEX01 |Set-TransportService -SendProtocolLogMaxAge 7.00:00:00
Get-TransportService SVEX01 |Set-TransportService -ReceiveProtocolLogMaxAge 7.00:00:00
Get-TransportService SVEX01 |Set-TransportService -TransportSyncHubHealthLogMaxDirectorySize 500MB

Get-TransportService SVEX01 |Set-TransportService -TransportSyncLogMaxDirectorySize 500MB

Также напомню, что если что-то ненужно, то не нужно и не можно это и собирать.

Get-EventLogLevel | where { $_.EventLevel -ge 1} | Set-EventLogLevel -Level 0

Что касается дисков с логами самих служб, я бы привел простенький oneliner:

gci ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging’,’C:\inetpub\logs’ -Directory | gci -Include ‘*.log’,’*.blg’ -Recurse | ? LastWriteTime -lt (Get-Date).AddDays(-1) | Remove-Item

Другой вариант решения проблемы- у Ильи в блоге

cu6


Что можно рассказать про релиз- столкнулся со странной ошибкой, которую не видел в предыдущей 5 версии:

4eddf4a5e1_8748103_8703523

Обновляется сервер, который находится за пределами сайта с ролью SM. Установщик плачет и пытается угадать, что не так, поругав меня за то, что я не вхожу в группы OM,SA, и придумывая другие страшные вещи, советуя все время проверять себя по требованиям установки.

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

После обновления осторожно проверил, все ли хорошо, и в том ли сайте оказался сервер.

Еще одна приятная неожиданность- это выпиливание setup.com и вколачивание его в setup.exe. Не совсем для меня очевидно, зачем так было сделано, но, говорят, так надо….

Третий нюанс апгрейда- после обновления схемы (на все том же , не-в-сайтовом сервере), уже новым модным способом

setup.exe /prepareAD, на обновленном сервере пропал smtp баннер, а сервер перестал принимать коннекты на 25 порту. Имейте это ввиду при обновлении схемы, и запланируйте время сразу на апгрейд- сервер после некритичной на первый взгляд операции по обновлении схемы перестал дружить со всеми по smtp 25. Помог другой workaround- в свойствах коннектора отвязать IPv4 и привязать обратно.

Далее, закладываемся на обновление первого сервера в организации +1 час к намеченному времени- мне обновление напомнило CU3, который все делал оооочень долго. Остальные серверы обновлялись бодрее, хотя замечу, что были менее производительны чем выбранный мной первым.

После обновления  наконец ушли ошибки счетчиков производительности, которые присутствовали в 5 версии ,и которые полагалось игнорировать.

Ну и напоследок,  немного ТЗ: если мы собрали DAG из двух  разных серверов, скажем SP1 и  CU5, то базы между участниками DAG  переезжать и активироваться будут, несмотря на то, что это официально не поддерживается. Не говорите никому :).

“Плохая” новость CU6 🙂 это уже не работает: нажатие кнопки activate в ЕСР, бодро позеленев, говорит, что все хорошо. (на группе DAG с разной версией- cu5 и сu6) А вот база при этом не активируется, то же самое и в posh. Ошибок нет, и активации нет- но все честно.

.net


Часто спрашивают- а как улучшить производительность сервера Exchange?

Отвечаю- надо следить за последними обновлениями и устанавливать их на сервера, улучшая их стабильность и производительность.

Искусство обновления лежит тут.

WinRM


Клиенту WinRM Shell не удается обработать запрос

 winrmfail

http://support.microsoft.com/kb/2027062/en

Продолжаем отлавливать баги с MS EXCHANGE 2013 :))

+ FullyQualifiedErrorId : -2144108212,PSSessionOpenFailed ПОДРОБНО: Подключение к xxx.xxx.RU New-PSSession : [xxx.xxx.RU] Сбой обработки данных, полученных от удаленного сервера xxx.xxx.RU. Сообщение об ошибке: Клиенту WinRM Shell не удается обработать запрос. Дескриптор оболочки, переданный функции WSMan Shell, недопустим. Дескриптор оболочки считается допустимым только в случае успешного завершения функции WSManCreateShell. Измените запрос, включив допустимый дескриптор оболочки, и повторите попытку. Подробности см. в разделе справки "about_Remote_Troubleshooting". строка:1 знак:1 + New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException + FullyQualifiedErrorId : -2144108212,PSSessionOpenFailed Не удалось подключиться к серверу Exchange на текущем сайте.

Причина (в моем случае) : Нет сертификата в IIS.

Лечение: Идем в консоль IIS -> Exchange BackEnd правой кнопкой мыши — изменить привязки. Проверить какой сертификат выставлен.

Если сертификата на бэкэнде нет, привяжите его. Грустно, что воспроизводится вплоть до CU5, если администратор протирал тряпочкой сертификаты. Грустно так же то, что свеже установленный сервер с дефолтным сертификатом его потерял на второй-третий день, после инсталляции- сервер расчехлялся, обновлялся и готов был бежать в бой. На cu6  баг пока не ловил.

WinRM


Последние два месяца были богаты траблшутом, и почему-то много выпадало на долю winrm.

Вот, к примеру, стоял Exchange 2010, никого не трогал, и внезапно отвалилась консоль управления сервером

kerb

Initialisation failed! The attempt to connect to SERVERNAME/powershell using Kerberos auth failed

Powershell тоже не цеплялся, что логично.

Проверяем: DNS, не то, билеты Kerberos, почти то, время в машинке- о, то. Чиним время и все хорошо.