Решение на данный момент: деинсталлировать апдейт 2449742. Ждем какого-нибудь исправления от Microsoft.

UPD: Проблема признана командой разработчиков Exchange, пока решение то же – не ставить данный апдейт.

UPD 2: Проблема решена, Microsoft выпустил исправление.

После этих манипуляций принтеры появлялись на клиентских ПК, но не работали, так как 64-битные драйверы с сервера конечно же не подходили:

Казалось бы, что может быть проще? Идем добавлять дополнительные драйверы на сервер, и получаем следующую ошибку:

Все дело в том, что дополнительные драйверы с отличающейся архитектурой нужно добавлять с хоста той же архитектуры. Пробуем добавить из-под ХР:

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

Оказалось, что при добавлении дополнительных драйверов их названия должны быть полностью идентичными. В нашем случае на сервере были установлены драйверы с названием HP LaserJet 1505n, а 32-битная версия называлась HP LaserJet  P1500 Series PCL5e, потому ничего и не работало. В случае с более новыми принтерами проблема решается скачиванием с сайта производителя  одинаковых драйверов для х32 и х64. Но и тут все было не так просто, мало того, что для 2008 сервера не было драйверов с таким же названием, так мы еще и не имели возможности поменять драйвер на ХР, потому что в этом случае одно очень важное приложение распечатывало страницы некорректно. К тому же у НР все официальные драйвера идут с приставкой series, поэтому даже если бы была возможность использовать другие драйвера на клиентах, то ничего бы не вышло.  Было сделано много предложений, как быть в такой ситуации, но в итоге сработало переименование драйверов в inf-файле. Файл выглядел так:

Сначала я попробовал изменить наименования драйвера только в секции, относящейся к русскоязычному CAB-файлу, но это результатов не дало. После этого я изменил в файле все записи HP LaserJet P1500 Series PCL5e на HP LaserJet 1505n.

Затем добавил драйвер из-под ХР, уже при добавлении было видно, что фокус сработал, оставалось понять, сработает ли это на сервере:

Смотрим результат на сервере:

Все получилось. После этих манипуляций принтеры инсталировались вместе с драйверами.

DPM 2010 RC интересен (кроме того, что его выход означает – релиз уже близко!) тем, что он поддерживает бэкап виртуальных машин кластера Hyper-V 2 с Cluster Shared Volumes. Чисто случайно как раз такой кластер оказался под рукой, поэтому было принято решение – устанавливать

Развертывание DPM 2010 RC открыло несколько любопытных вещей, которыми я и хочу поделиться:

DPM 2010 Release Candidate поддерживает простой апгрейд с DPM 2010 Beta. Я тестировал его на двух системах – одна инсталляция была выполнена на Windows Server 2008 R2, вторая – на Windows Server 2008 x64.

Beta-версия DPM 2010, кстати, нормально апгрейдится с DPM 2007 SP1 - устанавливает новый SQL-сервер, и апгрейдит старую базу DPMDB. Все параметры и бэкапы при этом сохранились. Как работает апгрейд с DPM 2007 на DPM 2010 RC – сказать пока не могу, не пробовал.

Апгрейд DPM 2010 Beta, стоящего на R2, прошел без проблем и вопросов. А вот для апгрейда той Betы, которая стоит на Windows Server 2008, инсталлятор попросил меня скачать и установить два патча – с номерами 975759 и 962975. Причем, эти патчи недоступны через Windows Update и выдаются по запросу на сайте – нужно только ввести свой e-mail.

После инсталляции вышеуказанных патчей апгрейд DPM прошел на ура. Кстати интересно - RC использует другой instance своего SQL-сервера, и если для Beta он назывался MSDPMV3BETA1EVAL, то для версии RC дополнительно ставится SQL instance с названием MSDPM2010RCEVAL. Базу данных инсталлятор переносит и обновляет сам – но не забудьте перед апгрейдом все-таки сделать ее резервную копию , а также удостовериться, что на диске хватит места под еще один экземпляр SQL Server 2008 и базу данных MSDPM.

Итак, после установки Release Candidate версия DPM станет 3.0.7558.0, вместо версии 3.0.7336.0 у Beta.

После апгрейда самого сервера нужно сапгрейдить и агенты DPM – для этого открываем консоль DPM, заходим в Management -> Agents, и нажимаем на ссылку Update Available рядом с каждым сервером.

Кстати говоря, на некоторые серверы через DPM агент по неясным причинам обновляться отказался – так и оставался в состоянии Needs Updating. Пришлось запускать на сервере установку агента вручную – из папки Agents дистрибутива DPM. После установки агента вручную достаточно нажать Refresh на странице консоли DPM.

Больше ничего с существующими Protection Group делать не надо – все предыдущие настройки и бэкапы сохраняются и подключаются нормально.

А вот при попытке добавить в Protection Group виртуальную машину с кластера Hyper-V, DPM выдал любопытное сообщение:

Это означает, что для резервного копирования виртуальных машин из кластера, и на виртуальной машине, и на каждом узле кластера должны стоять следующие обновления:

• Для Windows Server 2008 – 948465 (это просто Service Pack 2), и 971394.
• Для Windows Server 2008 R2 – 975921 и 975354.

Эти обновления опять-таки необходимо загружать с Microsoft по запросу, указывая свой e-mail, на который и придет ссылка для скачивания файлов, вместе с паролем.

Вот такие любопытные нововведения продолжаем исследовать RC, и ждем релиз.