Перенос сервера wsus на другой компьютер
собственно сервер существовал давно, был обновлен с версии 2 на 3, теперь необходимо заменить само железо на др. как корректно перетянуть? поднять еще один и подключить к тому?
Политика установки обновлений WSUS для рабочих станций
Мы предполагаем, что обновления на клиентские рабочие станции, в отличии от серверной политики, будут устанавливаться автоматически ночью сразу после получения обновлений. Компьютеры после установки обновлений должны перезагружаться автоматически (предупреждая пользователя за 5 минут).
В данной GPO (WorkstationWSUSPolicy) мы указываем:
В Windows 10 1607 и выше, несмотря на то, что вы указали им получать обновления с внутреннего WSUS, все еще могут пытаться обращаться к серверам Windows Update в интернете. Эта «фича» называется Dual Scan. Для отключения получения обновлений из интернета нужно дополнительно включать политику Do not allow update deferral policies to cause scans against Windows Update (ссылка).
Совет. Чтобы улучшить «уровень пропатченности» компьютеров в организации, в обоих политиках можно настроить принудительный запуск службы обновлений (wuauserv) на клиентах. Для этого в разделе Computer Configuration -> Policies-> Windows Setings -> Security Settings -> System Services найдите службу Windows Update и задайте для нее автоматический запуск (Automatic).
Групповая политика WSUS для серверов Windows
Начнем с описания серверной политики ServerWSUSPolicy.
Настройки групповых политик, отвечающих за работу службы обновлений Windows, находятся в разделе GPO: Computer Configuration -> Policies-> Administrative templates-> Windows Component-> Windows Update (Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Центр обновления Windows).
В нашей организации мы предполагаем использовать данную политику для установки обновлений WSUS на сервера Windows. Предполагается, что все попадающие под эту политику компьютеры будут отнесены к группе Servers в консоли WSUS. Кроме того, мы хотим запретить автоматическую установку обновлений на серверах при их получении. Клиент WSUS должен просто скачать доступные обновления на диск, отобразить оповещение о наличии новых обновлений в системном трее и ожидать запуска установки администратором (ручной или удаленной с помощью модуля PSWindowsUpdate) для начала установки. Это значит, что продуктивные сервера не будут автоматически устанавливать обновления и перезагружаться без подтверждения администратора (обычно эти работы выполняются системным администратором в рамках ежемесячных плановых регламентных работ). Для реализации такой схемы зададим следующие политики:
-
ConfigureAutomaticUpdates (Настройка автоматического обновления): Enable. 3 – Autodownloadandnotifyforinstall(Автоматически загружать обновления и уведомлять об их готовности к установке) – клиент автоматически скачивает новые обновлений и оповещает об их появлении;
Примечание. При настройке политики обновления советуем внимательно познакомиться со всеми настройками, доступными в каждой из опций раздела GPO Windows Update и задать подходящие для вашей инфраструктуры и организации параметры.
Все ответы
1. Поднять новый сервер wsus
2. Экспортировать БД на "старом": C:\Program Files\Update Services\Tools\wsusutil.exe export export.cab export.log
3. Перенести на "новый" директорию с обновлениями
4. Импортировать БД на "новом" C:\Program Files\Update Services\Tools\wsusutil.exe import export.cab export.log
5. Изменить GPO или скрипт для клиентов в целях перенаправления их на новый сервер
Добавлю, что если конфигурация расположения файлов точно такая же как на стратом сервере, то можно просто скопировать базу данных без экспорта-импорта (только сервисы нового WSUS и SQL остановите)/
сорри, отсутсвовал долго. спасибо за ответ! обязательно попробую, и отпишусь о рез-тах
Результат положительный, единственное импорт раз в 5 длился дольше чем экспорт и одобрения не выставляются приходится самому по памяти все восстанавливать.
вообщем сделал экспорт в лог файл, скопировал бд, причем у меня 2 папки, wsus и wsusdatabase (сначала был wsus2) устанавливаю wsus на новый сервер, выходит диалоговое окно с выбором вариантов установки,
где предлогается выбрать:
1. Существующую локальную базу данных виндовс (показываю то что скопировал) не прокатывает
2. Существующий сервер баз данных на этом компьюетер ( не активный)
3. Сервер баз данных на удаленном компьютере
теперб, если выбираю 1 пункт он пытается соединится с базой данных, типа SQl которого нет и ошибка. SQL у меня нет, не приобретали, что нужно? на др ведь функционирует! Ка развернуть локальную базу данных.
Если вы хотите взять старую базу, то сначала просто поставьте WSUS абсолютно точно так же как прежде - на тот же диск (в смысле по имени) и по тем же путям. После чего остановите WSUS и локальный SQL, подмените базу на старую и скопируйте старую папку с контентом WsusContent в новую. Запустите ранее остановленные сервисы.
все дело в том, что на новом сервере, куда хочу установить WSUS, стоял SQl2005, он был удален, и видимо из за него WSUS никак не хочет устанавливаться, т.е. настоятельно просит указать базу данных. Вернее, это был сервер SharePoint 3, и он функционировал на SQL, все было удалено, но при установке WSUS - он не разворачивает свою базу данных.
вообще так и не удалось по указанным причинам установить на этот сервер, сейчас устанавливаю на др, там все ровно пошло, так как не было Sharepoint.. Хоть он и был удален, но видимо все из за него, сейчас импортирую log
Что значит "скопировал БД" её нужно не копировать, а экспортировать также как и лог C:\Program Files\Update Services\Tools\wsusutil.exe export wsus.cab wsus.log
2. В качестве пути к базе не нужно указывать папку с экспортированными лог и БД, а просто укажите где вы хотите хранить файлы БД (директорию)
1. Поднять новый сервер wsus
2. Экспортировать БД на "старом": C:\Program Files\Update Services\Tools\wsusutil.exe export export.cab export.log
3. Перенести на "новый" директорию с обновлениями
4. Импортировать БД на "новом" C:\Program Files\Update Services\Tools\wsusutil.exe import export.cab export.log
5. Изменить GPO или скрипт для клиентов в целях перенаправления их на новый сервер
все ок, только надо одобрения заново устанавливать. впринципе вопрос решен, только не удалось установить на ту машину где раньше жил Sharepoint на SQL
сделал вот так:
1. Поднять новый сервер wsus
2. Экспортировать БД на "старом": C:\Program Files\Update Services\Tools\wsusutil.exe export export.cab export.log
3. Перенести на "новый" директорию с обновлениями
4. Импортировать БД на "новом" C:\Program Files\Update Services\Tools\wsusutil.exe import export.cab export.log
5. Изменить GPO или скрипт для клиентов в целях перенаправления их на новый сервер
все ок, только надо одобрения заново устанавливать. впринципе вопрос решен, только не удалось установить на ту машину где раньше жил Sharepoint на SQL
Только обновления видятся как "одобрено" но не "скачено". Как WSUS должен увидеть что обновления скачены?
Самый надежный и правильный ИМХО способ:
1. Поднять новую машину со WSUS.
2. На новой машину во WSUS поставить в качестве родительского сервера старую, включить свойство "реплика"
3. Запустить синхронизацию, дождаться пока пройдет синхронизация и перекачаются все файлы (эт видно на главной странице WSUS - у мну например это 60-70 Гб).
5. убедиться, что новые клиенты пошли на новый сервер (для ускорения процесса - wuauclt /resetauthorization и wuauclt /detect now)
18.03.2011
itpro
Windows Server 2003, Обновления
Комментариев пока нет
В этой статье я расскажу о том, как можно выполнить выполнить миграцию WSUS 3.0 на новый сервер при помощи переноса локального экземпляра SQL Express и без необходимости повторной загрузки всех обновлений. Перед переносом рекомендую удалить ненужные обновления на Wsus-сервере, это сэкономит место на новом сервере.
1. Установите WSUS на новый сервер с локальной базой данных SQL Express.
2. В процессе установки и настройки выберите пункт «Synchronize from another WSUS server…» (синхронизовать с другим сервером WSUS), введите имя существующего сервера WSUS, который планируется мигрировать, и отметьте опцию «This is a replica of the upstream server » (это реплика вышестоящего сервера).
3. Завершите мастер настройки сервера (часть опций будет пропущена, т.к. данный сервер является репликой вышестоящего сервера).
4. Дождитесь окончания процесса синхронизации. В результате будет выполнена синхронизация файлов обновлений, согласования т групп компьютеров, другие параметры сервера перенесены не будут. Данный шаг позволит сэкономить наше время и трафик, которые бы мы потратили на загрузку обновлений из интернета.
5. Измените настройки нового сервера с реплики на автономный (standalone).
6. Скачайте пакет WSUS API Samples and Tools с сайта Microsoft и установите его на каждом из серверов.
7. На старом сервер откройте командную строку и перейдите в каталог C:\Program Files\Update Services 3.0 API Samples and Tools\WsusMigrate\WsusMigrationExport .
8. Запустите команду «wsusmigrationexport.exe settings.xml «, выполняющую экспорт настроек Wsus 3.0. В результате вы получите файл с настройками старого сервера WSUS в формате XML.
9. Скопируйте файл XML на новый сервер.
10. На новом сервере также откройте командную строку и перейдите в папку C:\Program Files\Update Services 3.0 API Samples and Tools\WsusMigrate\WsusMigrationImport. Запустите команду «wsusmigrationimport.exe settings.xml All None «.
11. Задайте настройки на новом сервере WSUS (продукты и классификации, параметры подтверждения, email алерты и т.д.) в соответствии с настройками старого сервера.
12. Настройте объекты групповой политики (GPO) на клиентах таким образом, чтобы они все «смотрели» на новый сервер WSUS. В том случае, если вы используете групповые политики для того, чтобы отнести компьютеры к той или иной группе WSUS, то на этом процесс миграции Wsus можно считать оконченным. Если вы вручную относите компьютеры к той или иной группе на Wsus сервере, вам необходимо вручную после инициации клиента на сервере (появление в группе Unassigned Computers) перетащить такие ПК в нужную вам группу обновлений.
08.02.2019
itpro
Windows Server 2012 R2, Windows Server 2016
комментарий 21
В том случае, если вы устанавливаете обновления Microsoft на компьютеры и сервера компании с собственного сервера WSUS, вы, вероятно, перед установкой обновлений выполняете их тестирование на пилотных группах компьютерах или серверах (разнести компьютеры и сервера по разным группам WSUS можно с помощью GPO). Как показывает практика последних лет, нельзя оставлять WSUS, настроенным на автоматическое одобрение всех новых обновлений сразу на продуктивные системы (Microsoft выпускает очень много сырых и недостаточно протестированных обновлений).
На WSUS сервере можно организовать несколько различных групп обновлений. Классическая схема одобрения новых обновлений на WSUS сервере сводится к тому, что сначала выполняется их тестирование на тестовых группах ПК и серверов (допустим группах Workstation_Testи Servers_Test), на которых в настройках WSUS созданы правила автоматического одобрения всех новых критических обновлений и обновлении безопасности (WSUS -> Options -> Automatic Approvals -> Default Automatic Approval Rule).
После того, как новые обновления установлены на тестовую группу и получено подтверждение, что обновления не вызвали проблем у пользователей (обычно тестирование занимает 3-4 дня), необходимо одобрить новые обновления для установки на продуктивные группы. Но как это сделать, чтобы не пришлось вручную выбирать новые обновления и одобрять их установку на все компьютеры и сервера? Я покажу два довольно простых способа переноса одобренных обновлений с тестовых групп WSUS на продуктивные.
Назначаем политики WSUS на OU Active Directory
Следующий шаг – назначить созданные политики на соответствующие контейнеры (OU) Active Directory. В нашем примере структура OU в домене AD максимально простая: имеются два контейнера – Servers (в нем содержаться все сервера организации, помимо контроллеров домена) и WKS (Workstations –компьютеры пользователей).
Совет. Мы рассматриваем лишь один довольно простой вариант привязки политик WSUS к клиентам. В реальных организациях возможно привязать одну политику WSUS на все компьютеры домена (GPO с настройками WSUS вешается на корень домена), разнести различные виды клиентов по разным OU (как в нашем примере – мы создали разные политики WSUS для серверов и рабочих станций), в больших распределенных доменах можно привязывать различные WSUS сервера к сайтам AD, или же назначать GPO на основании фильтров WMI, или скомбинировать перечисленные способы.
Чтобы назначить политику на OU, щелкните в консоли управления групповыми политиками по нужному OU, выберите пункт меню Link as Existing GPO и выберите соответствующую политику.
Совет. Не забудьте про отдельную OU с контроллерами домена (Domain Controllers), в большинстве случаев на этот контейнер следует привязать «серверную» политику WSUS.
Точно таким же способом нужно назначить политику WorkstationWSUSPolicy на контейнер AD WKS, в котором находятся рабочие станции Windows.
Осталось обновить групповые политики на клиентах для привязки клиента к серверу WSUS:
Все настройки системы обновлений Windows, которые мы задали групповыми политиками должны появится в реестре клиента в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate.
Данный reg файл можно использовать для переноса настроек WSUS на другие компьютеры, на которых не удается настроить параметры обновлений с помощью GPO (компьютеры в рабочей группе, изолированных сегментах, DMZ и т.д.)
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://srv-wsus.winitpro.ru:8530"
"WUStatusServer"="http://srv-wsus.winitpro.ru:8530"
"UpdateServiceUrlAlternate"=""
"TargetGroupEnabled"=dword:00000001
"TargetGroup"="Servers"
"ElevateNonAdmins"=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"NoAutoUpdate"=dword:00000000 –
Также удобно контролировать применённые настройки WSUS на клиентах с помощью rsop.msc.
И через некоторое время (зависит от количества обновлений и пропускной способности канала до сервера WSUS) нужно проверить в трее наличие всплывающего оповещений о наличии новых обновлений. В консоли WSUS в соответствующих группах должны появиться клиенты (в табличном виде отображается имя клиента, IP, ОС, процент их «пропатченности» и дата последнего обновлений статуса). Т.к. мы политиками привязали компьютеры и серверы к различным группам WSUS, они будут получать только обновления, одобренные к установке на соответствующие группы WSUS.
Примечание. Если на клиенте обновления не появляются, рекомендуется внимательно изучить на проблемном клиенте лог службы обновлений Windows (C:\Windows\WindowsUpdate.log). Обратите внимание, что в Windows 10 (Windows Server 2016) используется другой формат журнала обновлений WindowsUpdate.log. Клиент скачивает обновления в локальную папку C:\Windows\SoftwareDistribution\Download. Чтобы запустить поиск новых обновлений на WSUS сервере, нужно выполнить команду:
Также иногда приходится принудительно перерегистрировать клиента на сервере WSUS:
wuauclt /detectnow /resetAuthorization
В особо сложных случаях можно попробовать починить службу wuauserv так. При возникновении ошибки 0x80244010 при получении обновлений на клиентах, попробуйте изменить частоту проверки обновлений на сервере WSUS с помощью политики Automatic Update detection frequency.
В следующей статье мы опишем особенности одобрения обновлений на сервере WSUS. Также рекомендуем ознакомиться со статьей о переносе одобренных обновлений между группами на WSUS сервере.
собственно сервер существовал давно, был обновлен с версии 2 на 3, теперь необходимо заменить само железо на др. как корректно перетянуть? поднять еще один и подключить к тому?
Ответы
1. Поднять новый сервер wsus
2. Экспортировать БД на "старом": C:\Program Files\Update Services\Tools\wsusutil.exe export export.cab export.log
3. Перенести на "новый" директорию с обновлениями
4. Импортировать БД на "новом" C:\Program Files\Update Services\Tools\wsusutil.exe import export.cab export.log
5. Изменить GPO или скрипт для клиентов в целях перенаправления их на новый сервер
Ответы
1. Поднять новый сервер wsus
2. Экспортировать БД на "старом": C:\Program Files\Update Services\Tools\wsusutil.exe export export.cab export.log
3. Перенести на "новый" директорию с обновлениями
4. Импортировать БД на "новом" C:\Program Files\Update Services\Tools\wsusutil.exe import export.cab export.log
5. Изменить GPO или скрипт для клиентов в целях перенаправления их на новый сервер
Копирование одобренных обновлений между группами WSUS с помощью PowerShell
В том случае, если у вас имеется множество групп обновлений на WSUS сервере, перенос одобренных обновлений с тестовых групп на продуктивные можно автоматизировать с помощью PowerShell. У меня получился такой скрипт, в котором нужно указать FQDN имя сервера WSUS, и имя групп, между которыми нужно скопировать одобренные обновления.
$WsusServerFqdn='msk-wsus.winitpro.loc'
$WsusSourceGroup = 'Workstation_Test'
$WsusTargetGroup = 'WorkstationProduction'
[void][reflection.assembly]::LoadWithPartialName( «Microsoft.UpdateServices.Administration»)
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer( $WsusServerFqdn, $False, ‘8530’)
$Groups = $wsus.GetComputerTargetGroups()
$WsusSourceGroupObj = $Groups | Where
$WsusTargetGroupObj = $Groups | Where
$Updates = $wsus.GetUpdates()
$i = 0
ForEach ($Update in $Updates)
if ($Update.GetUpdateApprovals($WsusSourceGroupObj).Count -ne 0 -and $Update.GetUpdateApprovals($WsusTargetGroupObj).Count -eq 0)
$i ++
Write-Host («Approving » + $Update.Title)
$Update.Approve(‘Install’,$WsusTargetGroupObj) | Out-Null
>
>
Write-Output («Approved updates for target group » -f $i, $WsusTargetGroup)
Данный PowerShell скрипт последовательно перебирает все одобренные обновления в исходной группе WSUS и, если обновление не одобрено на целевой группе, одобряет его установку. В данном примере скрипт одобрил 64 обновления, которые были одобрены в тестовой группе и отсутствовали в продуктивной.
08.02.2019
itpro
Групповые политики
комментариев 50
В одной из предыдущих статей мы подробно описали процедуру установки сервера WSUS на базе Windows Server 2012 R2 / 2016. После того, как вы настроили сервер, нужно настроить Windows-клиентов (сервера и рабочие станции) на использование сервера WSUS для получения обновлений, чтобы клиенты получали обновления с внутреннего сервера обновлений, а не с серверов Microsoft Update через Интернет. В этой статье мы рассмотрим процедуру настройки клиентов на использование сервера WSUS с помощью групповых политик домена Active Directory.
Групповые политики AD позволяют администратору автоматически назначить компьютеры в различные группы WSUS, избавляя его от необходимости ручного перемещения компьютеров между группами в консоли WSUS и поддержки этих групп в актуальном состоянии. Назначение клиентов к различным целевым группам WSUS основывается на метке в реестре на клиенте (метки задаются групповой политикой или прямым редактированием реестра). Такой тип соотнесения клиентов к группам WSUS называется client side targeting (Таргетинг на стороне клиента).
Предполагается, что в нашей сети будут использоваться две различные политики обновления — отдельная политика установки обновлений для серверов (Servers) и для рабочих станций (Workstations). Эти две группы нужно создать в консоли WSUS в секции All Computers.
Совет. Политика использования сервера обновлений WSUS клиентами во многом зависит от организационной структуры OU в Active Directory и правил установки обновлении в организации. В этой статье мы рассмотрим всего лишь частный вариант, позволяющий понять базовые принципы использования политик AD для установки обновлений Windows.
В первую очередь необходимо указать правило группировки компьютеров в консоли WSUS (targeting). По умолчанию в консоли WSUS компьютеры распределяются администратором по группам вручную (server side targeting). Нас это не устраивает, поэтому укажем, что компьютеры распределяются в группы на основе client side targeting (по определенному ключу в реестре клиента). Для этого в консоли WSUS перейдите в раздел Options и откройте параметр Computers. Поменяйте значение на Use Group Policy or registry setting on computers (Использовать на компьютерах групповую политику или параметры реестра).
Теперь можно создать GPO для настройки клиентов WSUS. Откройте доменную консоль управления групповыми политиками (Group Policy Management) и создайте две новые групповые политики: ServerWSUSPolicy и WorkstationWSUSPolicy.
Ответы
1. Поднять новый сервер wsus
2. Экспортировать БД на "старом": C:\Program Files\Update Services\Tools\wsusutil.exe export export.cab export.log
3. Перенести на "новый" директорию с обновлениями
4. Импортировать БД на "новом" C:\Program Files\Update Services\Tools\wsusutil.exe import export.cab export.log
5. Изменить GPO или скрипт для клиентов в целях перенаправления их на новый сервер
Способ переноса одобренных обновлений в консоли WSUS
Вы можете достаточно удобно вручную скопировать одобренные обновления с тестовой группы WSUS на продуктивную группу компьютеров/серверов. Для этого нужно правильно настроить консоль Update Services.
В разделе Updates нужно создать новое представление для одобренных обновлений тестовой группы. Для этого выберите пункт меню New Update View.
В открывшемся мастере выберите пункт “Updates are approved for a specific group” (одобрения, одобренные для указанной группы) и укажите имя тестовой группы WSUS (Workstation_test). Укажите имя нового представления.
Выберите созданное вами представление и в меню фильтров выберите пункт Approval=”Approved” и Status=”Any”. Щелкнув по заголовку таблицы добавьте столбец, в котором указана дата выпуска обновления (Release Date). Щелкнув по имени столбца, отсортируйте список обновления, чтобы новые обновления оказались вверху.
Как вы видите, теперь в списке можно легко найти новые обновления и проверить статус их установки. С помощью клавиш Shift и/или Ctrl можно выбрать все необходимые обновления, которые нужно одобрить на продуктивных системах, вызвать контекстное меню правым щелчком мыши и выбрать пункт Approve. В списке групп WSUS выберите продуктивные группы, для которых нужно одобрить выделенные обновления и выберите пункт Approved for Install.
Теперь новые обновления будут устанавливать и на продуктивных системах.
Все ответы
1. Поднять новый сервер wsus
2. Экспортировать БД на "старом": C:\Program Files\Update Services\Tools\wsusutil.exe export export.cab export.log
3. Перенести на "новый" директорию с обновлениями
4. Импортировать БД на "новом" C:\Program Files\Update Services\Tools\wsusutil.exe import export.cab export.log
5. Изменить GPO или скрипт для клиентов в целях перенаправления их на новый сервер
Добавлю, что если конфигурация расположения файлов точно такая же как на стратом сервере, то можно просто скопировать базу данных без экспорта-импорта (только сервисы нового WSUS и SQL остановите)/
сорри, отсутсвовал долго. спасибо за ответ! обязательно попробую, и отпишусь о рез-тах
Результат положительный, единственное импорт раз в 5 длился дольше чем экспорт и одобрения не выставляются приходится самому по памяти все восстанавливать.
вообщем сделал экспорт в лог файл, скопировал бд, причем у меня 2 папки, wsus и wsusdatabase (сначала был wsus2) устанавливаю wsus на новый сервер, выходит диалоговое окно с выбором вариантов установки,
где предлогается выбрать:
1. Существующую локальную базу данных виндовс (показываю то что скопировал) не прокатывает
2. Существующий сервер баз данных на этом компьюетер ( не активный)
3. Сервер баз данных на удаленном компьютере
теперб, если выбираю 1 пункт он пытается соединится с базой данных, типа SQl которого нет и ошибка. SQL у меня нет, не приобретали, что нужно? на др ведь функционирует! Ка развернуть локальную базу данных.
Если вы хотите взять старую базу, то сначала просто поставьте WSUS абсолютно точно так же как прежде - на тот же диск (в смысле по имени) и по тем же путям. После чего остановите WSUS и локальный SQL, подмените базу на старую и скопируйте старую папку с контентом WsusContent в новую. Запустите ранее остановленные сервисы.
все дело в том, что на новом сервере, куда хочу установить WSUS, стоял SQl2005, он был удален, и видимо из за него WSUS никак не хочет устанавливаться, т.е. настоятельно просит указать базу данных. Вернее, это был сервер SharePoint 3, и он функционировал на SQL, все было удалено, но при установке WSUS - он не разворачивает свою базу данных.
вообще так и не удалось по указанным причинам установить на этот сервер, сейчас устанавливаю на др, там все ровно пошло, так как не было Sharepoint.. Хоть он и был удален, но видимо все из за него, сейчас импортирую log
Что значит "скопировал БД" её нужно не копировать, а экспортировать также как и лог C:\Program Files\Update Services\Tools\wsusutil.exe export wsus.cab wsus.log
2. В качестве пути к базе не нужно указывать папку с экспортированными лог и БД, а просто укажите где вы хотите хранить файлы БД (директорию)
1. Поднять новый сервер wsus
2. Экспортировать БД на "старом": C:\Program Files\Update Services\Tools\wsusutil.exe export export.cab export.log
3. Перенести на "новый" директорию с обновлениями
4. Импортировать БД на "новом" C:\Program Files\Update Services\Tools\wsusutil.exe import export.cab export.log
5. Изменить GPO или скрипт для клиентов в целях перенаправления их на новый сервер
все ок, только надо одобрения заново устанавливать. впринципе вопрос решен, только не удалось установить на ту машину где раньше жил Sharepoint на SQL
сделал вот так:
1. Поднять новый сервер wsus
2. Экспортировать БД на "старом": C:\Program Files\Update Services\Tools\wsusutil.exe export export.cab export.log
3. Перенести на "новый" директорию с обновлениями
4. Импортировать БД на "новом" C:\Program Files\Update Services\Tools\wsusutil.exe import export.cab export.log
5. Изменить GPO или скрипт для клиентов в целях перенаправления их на новый сервер
все ок, только надо одобрения заново устанавливать. впринципе вопрос решен, только не удалось установить на ту машину где раньше жил Sharepoint на SQL
Только обновления видятся как "одобрено" но не "скачено". Как WSUS должен увидеть что обновления скачены?
Самый надежный и правильный ИМХО способ:
1. Поднять новую машину со WSUS.
2. На новой машину во WSUS поставить в качестве родительского сервера старую, включить свойство "реплика"
3. Запустить синхронизацию, дождаться пока пройдет синхронизация и перекачаются все файлы (эт видно на главной странице WSUS - у мну например это 60-70 Гб).
5. убедиться, что новые клиенты пошли на новый сервер (для ускорения процесса - wuauclt /resetauthorization и wuauclt /detect now)
Читайте также: