При выходе из клиента OWA на странице выхода доступна только одна кнопка “Закрыть окно/Close Window”. При попытке заново запустить OWA будет необходимо заново в адресной строке указывать место расположения OWA, что очень неудобно. Ситуацию можно упростить добавив кнопку входа на страницу выхода, которая будет перемещать нас на страницу входа, где можно будет заново ввести логин и пароль.

Чтобы сделать вышенаписанное необходимо немного отредактировать файл logoff.aspx который находится здесь – %ProgramFiles%MicrosoftExchange ServerClientAccessOwaauth. Открываем его и ищем строку LogoffClose. Перед открывающей скобкой html-тэга input, который содержит LogoffClose вставляем следующий код:

<input id="btnCls" type="submit" title="<%=LocalizedStrings.GetHtmlEncoded(Strings.IDs.LogOn)
 >" value="<%=LocalizedStrings.GetHtmlEncoded(Strings.IDs.LogOn) >" 
onclick="window.navigate('https://mail.contoso.com/owa')" 
onmouseover="this.className='btnOnMseOvr'" onmouseout="this.className='btn'" 
onmousedown="this.className='btnOnMseDwn'">

Результат выглядит примерно следующим образом:

При нажатии кнопки вход браузер нас перекидывает на страницу ввода логина/пароля.

Следует помнить, что перед вставкой кода желательно старый logoff.aspx забэкапить. Кроме этого, при установке сервис паков/обновлений на Exchange этот файл может быть перезаписан и его придётся править заново.

Скрипт взял отсюда.

Суть проблемы следующая. Имеются общие папки в виде листов задач, которые должны отсылать сообщения ответственным сотрудникам в случае создания новой задачи. В Exchange 2003 для этого с помощью Folder Assistant’а создавались правила, которые и занимались отсылками сообщений. При переносе на Exchange 2007 часть этих правил перестала работать. При попытке их применить правила отключались и в лог уходила ошибка:

Provider: MSExchangeIS Public Store
EventID: 1041
Channel: Application
Computer:
EventData: The rule “1-D3F1FE7FAD” with the sequence number 100 was disabled due to the error -2147221220 that was encountered while applying the rule.

Subject of the message that caused this error is “xxx”
Problem was found in the function “EcDoPublicFolderRules”.
The public folder is “xxx” on the database “xxx”

Некоторое время, потраченное на поиск вывело сюда. Смысл происходящего – в Exchange 2007 изменился механизм отработки правил в общих папках. В Exchange 2003 папке, в которой включалось правило, по умолчанию выдавался почтовый адрес. В Exchange 2007 этот адрес пришлось выдавать вручную, делая эту папку mail-enabled. После того как эта операция была проделана с проблемной папкой – правила стали нормально отрабатывать.

Как-то без особого шума вышел третий сервис пак для Exchange 2007. Скачать можно отсюда. Описание здесь. Из нового появилось следующее:

  • Поддержка установки на Windows 2008 R2 и Windows 7
  • Password Reset Tool для IIS
  • Обновление компонента Exchange Search до версии 3.1
  • Изменения в схеме AD с новыми аттрибутами для роли UM
  • Поддержка подписей для языков, где буквы пишутся справа налево (типа арабского и иврита)

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

После выхода четвёртого серис-пака для Enterprise Vault 8.0 я попытался его установить на текущий сервер Enterprise Vault и столкнулся с удивительной вещью – в одном из предыдущих сервис-паков из SCL пропала поддержка 32-битной версии Windows 2008, а в sp4 это ограничение появилось и в Deplyment Scanner’е. В итоге я оказался поставлен перед фактом – чтобы поставить sp4 (а в дальнейшем и перейти на версию 9.0) мне необходимо перейти либо на Windows 2008 R2, либо на 64-битную версию Windows 2008.

Процедура миграции выглядит следующим образом.

1. Необходимо очистить очередь MSMQ перед началом процесса миграции. Обычно очередь сама очищается после остановки сервиса Task Controller.

2. Как только очередь очистится – останавливаем все сервисы EV.

3. Экспортируем следующие ветки реестра:

  • HKLMSoftwareKVSEnterprise VaultIndexing
  • HKLMSoftwareKVSEnterprise VaultStorage
  • HKLMSoftwareKVSEnterprise VaultExternal Filtering

и ключи:

  • HKLMSystemCurrentControlSetServicesMRXSmbParametersOplocksDisabled
  • HKLMSystemCurrentControlSetControlSession ManagerMemory ManagementPoolUsageMaximum
  • HKLMSystemCurrentControlSetControlSession ManagerMemory ManagementPagedPoolSize
  • HKLMSoftwareMicrosoftMSMQParametersKernelMemThreshold
  • HKLMSystemCurrentControlSetServicesTcpipParametersEnableTCPChimney
  • HKLMSystemCurrentControlSetServicesTcpipParametersEnableRSS
  • HKLMSystemCurrentControlSetServicesTcpipParametersEnableTCPA

Если каких-то веток/ключей не будет – то создавать их на новом сервере не надо.

4. Устанавливаем ОС и EV на новый сервер. Устанавливаем все необходимые обновления. Имя сервера оставляем прежним, как и его сетевые настройки. EV ставим в ту же директорию, что и на старом сервере.

5. На новый сервер необходимо скопировать файлы в те же папки, где они находились на старом сервере:

  • Vault Stores
  • Indexing files
  • Shopping files
  • Reports
  • Custom Filter Rules

Если часть файлов находится на внешнем хранилище – задача облегчается. Достаточно внешнее хранилище переподключить к новому серверу.

6. Импортируем на новый сервер ветки и ключи реестра, экспортированные в пункте 3.

7. Через консоль SQL подключаемся к базе EnterpriseVaultDirectory. В таблице StorageServiceEntry находим данные, связанные со старым сервером, в столбцах StorageArchive, StorageRestore, StorageReplayIndex, StorageSpool и удаляем их (если серверов несколько, то эти данные будут в одной строке). В таблице RetrievalTask находим данные, связанные со старым сервером, в столбцах RetrievalSpoolQueue, MessageQueue и удаляем их (если серверов несколько, то эти данные будут в одной строке). В таблице ArchivingRetrievalTask находим данные, связанные со старым сервером, в столбце MessageQueue и удаляем его. Если сервер только один, то можно использовать следующий скрипт:

USE EnterpriseVaultDirectory
UPDATE StorageServiceEntry
SET StorageArchive = ' ', StorageRestore = ' ', StorageReplayIndex = ' ', StorageSpool = ' '
UPDATE RetrievalTask
SET RetrievalSpoolQueue = ' ', MessageQueue = ' '
UPDATE ArchivingRetrievalTask
SET MessageQueue = ' '

8. На сервере EV запускаем Enterprise Vault Configuration. Выбираем создать новую директорию. После указания SQL-сервера, который содержит исправленную на предыдущем шаге базу, выскочит сообщение что сервер уже найден в базе и запустится процесс восстановления. По завершении которого будет восстановлена старая конфигурация.

9. Нужно проконтролировать, что сервисы EV Admin и Directory стартовали. Если нет – запускаем их вручную. После этого запускаем остальные сервисы EV.

10. Если использовался плагин для OWA, то необходимо повторно запустить скрипт owauser.wsf.

Оригинал инструкции находится здесь.

В связи с неудавшимся обновлением Backup Exec 12.5 => 2010 пришлось столкнуться с необходимостью аварийного восстановления Backup Exec, совмещённого с переездом с 32-битной платформы на 64-битную и обновлением версии операционной системы с 2003 на 2008. Ниже описан процесс такого восстановления/перемещения.

Процедура перемещения состоит из нескольких шагов.

  • Готовим исходный медиа-сервер к перемещению – фактически собираем всю необходимую информацию для переноса на новый сервер и копируем её на внешний носитель/сервер
  • Устанавливаем новый медиа-сервер на тот же сервер (или на новый)
  • Восстанавливаем скопированную информацию с внешнего носителя на новый сервер и проверяем, что все настройки верно восстановились.

В моём случае предполагается, что серверное железо не меняется. Меняется ОС и версия Backup Exec. Описываемую процедуру Симантек НЕ советует делать самостоятельно, так что использовать можно на свой страх и риск =)

Подготовительный этап

1. Если есть возможность – категорически советую снять образ системного диска, чтобы в случае чего можно было сделать откат назад.

2. На всякий случай переписываем пути к папкам Backup-To-Disk:

3. Останавливаем все сервисы Backup Exec и SQL поддерживающий базу Backup Exec:

  • Backup Exec Agent Browser
  • Backup Exec Device and Media Service
  • Backup Exec DLO Administration Service (если установлена DLO)
  • Backup Exec DLO Maintenance Service (если установлена DLO)
  • Backup Exec Job Engine
  • Backup Exec Remote Agent for Windows Servers
  • Backup Exec Server
  • SQL Server (BKUPEXEC) (если Backup Exec использует локальную SQL Express)
  • SQL Server (MSSQLSERVER) (если Backup Exec использует удалённый сервер SQL) – сервис находится на удалённом сервере (стоит помнить, что в случае остановки этого сервиса перестанут отвечать все базы, которые находятся на нём)

4. Копируем следующие каталоги:

  • C:Program FilesSymantecBackup ExecData (кроме файлов *.dat)
  • C:Program FilesSymantecBackup ExecCatalogs
  • C:Program FilesSymantecBackup ExecIDR (если присутствует)
  • C:Program FilesSymantecBackup ExecReportsSaved
  • Папки Backup-To-Disk (если они находятся на DAS/NAS/SAN, то можно не копировать, в дальнейшем, на новом сервере, просто их переподключить)

Установка нового медиа-сервера

5. Устанавливаем на сервер новую ОС и новую версию Backup Exec. Устанавливаем все обновления и на ОС и на Backup Exec. Подключаем все внешние хранилища, если были.

Восстановление скопированной информации

6. Останавливаем все сервисы из пункта 3.

7. Копируем на новый сервер все папки, скопированные в пункте 4 (возможно, за исключением папок Backup-To-Disk).

8. Необходимо обновить версию файла базы данных Backup Exec, иначе сервисы Backup Exec просто не запустятся. Делается это с помощью утилиты bemig.exe. Может потребоваться скопировать файлы базы (BEDB_dat.mdf и BEDB_log.LDF) в папку C:Program FilesSymantecBackup ExecData.

8.1 Перед запуском утилиты необходимо внести изменения в реестр в ветке HKLMSoftwareSymantecBackup Exec for WindowsBackup ExecНомер версииInstall. Добавляем в неё ключи ‘Upgrade’ (тип Dword, значение 1) и ‘Upgrade Version’ (тип String, значение выбираем из таблицы ниже по версии продукта, с которого обновляем базу:

Product Version Upgrade Version Can Upgrade To
9.1 build 4691 9.1.4691.0 10x 11x
10.0 build 5484 10.0.5484.0 10x 11x
10.0 build 5520 10.0.5520.0 10x 11x
10.1 (10d) Build 5629 10.1.5629.0 11x 12.0
11 build 6235 11.0.6235.0 11x 12.0 12.5 2010
11 build 7170 11.0.7170.0 12.0 12.5 2010
12.0 12.0.1364.0 12.5 2010
12.5 12.5.2213.0 2010
2010 13.0.2896.0

То есть, если обновляемся с версии 12.5 на 2010, то указываем в качестве значения 12.5.2213.0)

8.2 Открываем командную строку, идём в папку Program FilesSymantecBackup Exec и запускаем bemig.exe. Процесс обновления файла базы будет комментироваться на экране. По успешному завершению обновления можно приступать к следующему шагу, в противном случае можно прогнать утилиту bemig.exe ещё раз.

9. С помощью утилиты beutility.exe копируем обновлённую базу в текущую.

Нужно будет указать для копирования файлы обновлённые утилитой bemig.exe на предыдущем шаге. После чего выскочит предупреждение о том, что сейчас будет перезаписана текущая база и запустится процесс копирования. По завершении копирования нужно будет нажать кнопку Close.

beutility.exe должна запустить все нужные сервисы. Если этого не произошло – запускаем их вручную. Список – в пункте 3.

В итоге мы получаем медиа-сервер Backup Exec новой версии на новой платформе новой ОС. После запуска консоли Backup Exec на закладке Devices наш новый медиа-сервер может быть в задвоенном виде. После перезапуска сервисов из пункта 3 задвоенность должна пропасть.

Ещё раз скажу – Симантек НЕ рекомендует самостоятельно проделывать операции изложенные выше. Я на это пошёл только из-за того, что миграция BE12.5(Win2003x86) => BE12.5(Win2008x86) => BE2010 (Win2008x86) поломалась уже на втором шаге, а поддержка Симантека ничем помочь мне не смогла – пришлось делать аварийное восстановление на новую ОС и сразу ставить новый Backup Exec.

Следующие статьи были использованы: