Замена сертификата на Exchange 2007

Запрос нового сертификата

Запрос нового сертификата нужно осуществлять только с помощью PowerShell и командлета New-ExchangeCertificate.

New-ExchangeCertificate -GenerateRequest -IncludeAutoDiscover -PrivateKeyExportable $true
-SubjectName "CN=owa.pubdomain.ru, O=ALVIK LLC, C=RU"
-DomainName exch.domain.local, owa.pubdomain.ru,  mail.pubdomain.ru
-FriendlyName "Microsoft Exchange 2007" -Path c:\exchange2007-cert.req

На что следует обратить внимание?

GenerateRequest — он сигнализирует о создании файла запроса на сертификат в сторонний центр сертификации. Без указания данного флага Exchange сервер сгенерирует самоподписанный сертификат.

SubjectName — поле CN должно в точности повторять FQDN к которому происходит обращение клиентов.

DomainName — должен содержать все альтернативные доменные имена, если таковы имеются. В моем случае пригодилось внутреннее имя сервера.

IncludeAutoDiscover — при наличии данного флага в запрос добавляются записи вида autodiscovery.domain.local для всех обслуживаемых доменов. Очень удобный параметр, не нужно в ручную перечислять данные записи.

PrivateKeyExportable — данный флаг позволит нам в дальнейшем экспортировать сертификат с закрытым ключем для передачи его на Isa Server 2006.

После выполнения данной операции будет сформирован текстовый файл запроса, который нужно передать в центр сертификации.

Открываем центр сертификации по адресу http://CA-Name/certsrv/ и делаем расширенный запрос сертификата:

Выбираем расширенный запрос сертификата:

Вставляем текст запроса:

После окончания операции мы получим .cer файл с новым сертификатом.

А где же закрытый ключ?

Естественно .cer файл не содержит закрытого ключа и на этом этапе обычно возникают трудности. Кажется, что сделал что-то не так, но все идет по плану.Exchange 2007 сам генерирует закрытый ключ и оставляет его в контейнере с запрошенным сертификатом и только после завершения процедуры импорта две половинки целого вновь соединятся и мы сможем получить долгожданный .pfxфайл.

Импорт сертификата необходимо опять выполнять через PowerShell.

Import-ExchangeCertificate c:\certnew.cer

В результате импорта Exchange 2007 покажет вам отпечаток сертификата:

2FF1AB2A04C03480387D93175F939120CC855E4F

Можно «запомнить» данное значения для легкости дальнейшего поиска и работы с сертификатом.

Теперь включаем данный сертификат в работу на требуемые службы в нашем случае это IIS и SMTP.

Enable-ExchangeCertificate 2FF1AB2A04C03480387D93175F939120CC855E4F -Services IIS,SMTP,POP3,IMAP
Если будет ругаться на отсутствие закрытого ключа, то ниже описано как исправить с помощью утилиты certutil.
Теперь можно экспортировать сертификат для передачи его на ISA Server.

Эту операцию можно сделать через оснастку «Сертификаты» в MMC, либо командлетом PowerShell

Export-ExchangeCertificate C84F388FB0A141CB4464B45A8AFC4F185FE3A5C1
   -Password P@ssw0rd -Path d:\exch-for-isa.pfx

Если вы будете делать экспорт сертификата средствами консоли MMC не забудьтеснять галочку «Включить усиленную защиту ключа».

Взято отсюда, на память. Спасибо

Устранение неполадок с закрытым ключом с помощью команды certutil -repairstore

---

1. Откройте консоль управления (MMC) и добавьте оснастку «Сертификаты». Для этого нажмите кнопку Пуск, выберите пункт Выполнить и введите mmc.exe
2. Дважды щелкните импортированный сертификат в папке «Личные».
3. Откройте вкладку Сведения.
4. Щелкните пункт Серийный номер в столбце «Поле», выделите серийный номер и запишите его.
5. Откройте командную строку.
6. Введите: certutil -repairstore my «серийный_номер» (где «серийный_номер» — это серийный номер, записанный в действии 4).
7. В оснастке «Сертификаты» щелкните правой кнопкой мыши пункт Сертификаты и выберите команду Обновить. Сертификату будет назначен закрытый ключ.
8. Чтобы проверить, устранена ли проблема, выполните командлет Get-ExchangeCertificate, который должен выводить правильный сертификат.

Проверка версии MS SQL server

Делаем по сути простенький, но часто забываемый запрос

SELECT SERVERPROPERTY(‘productversion’), SERVERPROPERTY (‘productlevel’), SERVERPROPERTY (‘edition’)

Запустить 1С 8.2 в режиме отладки

1. Остановливаем службу 1C:Enterprise 8.2 Server Agent
2. В реестре в ветке HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\1C:Enterprise 8.2 Server Agent\ для параметра ImagePath добавляем -debug в конце строчки и сохраняем.

Например: «C:\Program Files (x86)\1cv82\8.2.15.301\bin\ragent.exe» -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d «C:\Program Files (x86)\1cv82\srvinfo» -debug
3. запускаем службу

Не закрывается подключение к RDP

если сохранен профиль RDP, в котором указана программа для запуска, то при ее закрытии сеанс должен завершаться.

Если этого не происходит — смотрим процесс пользователя в диспетчере терминалов, на котором происходит зависание.

В 2008 это скорее всего будет SplWOW64.exe
Этот процесс нужно «подталкнуть» к завершению виндой:
regedit; в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\SysProcs добавляем DWORD: {имя_процесса.ехе} со значением 0.

Перезагружаем, проверяем.

Корпоративный чат на базе Openfire. Прозрачная авторизация.

Стоял успешно Openfire  3.7.  Недавно вышла версия 3.8, и я подзабыл уже как и что делать надо. Поэтому эта запись больше для себя, если вам поможет — буду рад.

Ставим Openfire как обычно, проходим настройку. В версии 3.8.0 были проблемы с ростерами, поэтому обновляем night сборкой до 3.8.1 alfa, просто копируя все поверх. Затем патчим для прозрачной авторизации. Берем его отсюда. Делаем все по инструкции внутри:

1. копируем файлы в каталог с установкой.

2. в файле \jre\lib\security\java.security после строк

security.provider.8=sun.security.smartcardio.SunPCSC
security.provider.9=sun.security.mscapi.SunMSCAPI

вставляем строку

security.provider.10=net.za.darkskies.security.sasl.SSPIProvider

3. в файл \conf\openfire.xml после тега <jive> добавляем

<sasl>
<mechs>ANONYMOUS,PLAIN,DIGEST-MD5,CRAM-MD5,NTLM</mechs>
<realm>[openfire_server]</realm>
</sasl>

4. Заходим на страницу администрирования Server Manger > System Property и создаем параметр sasl.realm
Значением параметра устанавливаем NETBIOS-NAME ДОМЕНА!!!
5. Там же находим параметр sasl.approvedRealms и УДАЛЯЕМ его если у вас ОДИН домен.
Создаем параметр sasl.mechs — ANONYMOUS,PLAIN,NTLM
Создаем параметр provider.authorization.classList со значением (одной строкой!) —
org.jivesoftware.openfire.sasl.StrictAuthorizationPolicy org.jivesoftware.openfire.sasl.DefaultAuthorizationPolicy

Вроде все, перезапускаем, пробуем авторизоваться мирандой.

Тонкости System Properties:

ldap.adminDN     domen\admin

ldap.baseDN        dc=»example»,dc=»com»

ldap.host               example.com

sasl.realm               EXAMPLE       //Обязательно заглавными

xmpp.domain       openfire        //Имя хоста с openfire

Перенос системных баз данных MS SQL 2008

Системная база данных tempdb.mdf и лог транзакций templog.ldf по умолчанию находятся в «c:\Program Files\Microsoft SQL Server\MSSQL10_50.CS1CKA\MSSQL\DATA\»   (SQL 2008R2)

1C 8.2 очень активно эти базы использует, для повышения производительности переносим обязательно.

Убеждаемся в пути:

SELECT name, physical_name AS CurrentLocation

FROM sys.master_files

WHERE database_id = DB_ID(N’tempdb’);

GO

Меняем путь:

USE master;

GO

ALTER DATABASE tempdb

MODIFY FILE (NAME = tempdev, FILENAME = ‘D:\Data\tempdb.mdf’);

GO

ALTER DATABASE tempdb

MODIFY FILE (NAME = templog, FILENAME = ‘D:\Log\templog.ldf’);

GO

Зависает клиент 1с 8.2

Недавно поставили сотруднице новый комп, i5 и все дела. Порадовавшись пару дней, стала жаловаться на долгое открытие форм отчетности в 1с, ужасно долгое формирование ОСВ и т.п.

Отмахивался от нее неделю, в результате пришлось разбираться.  Дошло дело b до конфигов sql,  и до netsh interface tcp set global autotuning= HighlyRestricted и т.п. вещей.  Ничто не помогало.

Оказалось все банальней, просочился какой-то зловредный многими любимый punto switcher. После его прибивания из авторана — все залетало.

Удаление dhcp сервера из AD

При понижении роли КД забыл удалить dhcp, выкашиваем его с любого другого контроллера из схемы командой

netsh dhcp delete server server_fqdn server_ip

Медленное открытие документов MS Office

Однажды к концу рабочего дня пожаловались несколько юзеров на внезапное долгое открытие документов офиса.

Не стал торопиться сносить офисы, переустанавливать, а решил найти источник проблемы. Тормоза при открытии документов возникали именно из проводника, из другого файлового менеджера (tcm) все работало на ура. Отключение антивируса, принтеров, спулера и т.п. вещей не помогало. Оказалось все банальнее. В этот день был выведен из эксплуатации один из контроллеров домена. А на некоторых пк был установлен пдф принтер, запускаемый с того КД (руки б оторвал…). Помогло поиск по реестру имени старого КД, и удаление ссылок на него.

Естественно проблема может возникнуть при другом любом ПО ссылающейся в сеть. Удачи в поисках!)