RootUsers

Guides, tutorials, reviews and news for System Administrators.

Windows Server Maintenance Checklist

Server maintenance needs to be performed regularly in order to ensure that your server will continue to run with minimal problems, while a lot of maintenance tasks are automated within the Windows operating system now there are still things that need to be checked and monitored regularly to ensure that Windows is running optimally. Below are steps that should be taken in order to maintain your servers.

Updates

Windows updates have been installed within the last month.
Keeping your server up to date is one of the most important maintenance tasks that needs to be done. Before applying updates to your server, confirm that you have a recent backup or snapshot if working with a virtual machine so that you have the option of reverting back if the updates cause you any unexpected problems.

If possible you should aim to test updates on a test server first if you are applying them to a production server. This allows you to first confirm that the updates will not break your server and will be compatible with any other packages or software that you may be running. If possible make use of a WSUS server, this will allow you to approve and control the updates that go to particular server groups in your environment.

You can apply updates through Windows Update which is accessible through Start > Control Panel > System and Security > Windows Update, or by just typing Windows Update into the Start search box. From here you can check for and install updates and select if they should download and install automatically which is enabled by default and the recommended option. It may not always be possible to have production servers rebooting whenever there are updates even out of hours so you may need to disable these and schedule in updates and reboots as required. If you have many servers you can configure Windows updates through group policy instead of locally on each server, basically it’s going to depend on your environment as to how this best works for you.

Other applications have been updated within the last week.
Other web applications such as WordPress/Drupal/Joomla for example, need to be frequently updated. This is because these sorts of applications act as a gateway to your server, usually by being more accessible than direct server access and by allowing public access in from the Internet. Lots of web applications may well also have third party plugins installed which can be coded by anyone, potentially having many security vulnerabilities with code that has not been audited.

As such it is critical to update these sorts of applications installed on your server very frequently. These content management systems are not managed through Windows updates as they are standalone pieces of software. They may have update functions within them or otherwise you may need to manually download and apply updates from an online source, if you’re unsure contact the application provider for further assistance.

Security

Server access reviewed within the last 6 months.
To increase security you should review who has access to your server. In any given organization you may have staff who have left but still have accounts with access; these should be removed or disabled. There may be local accounts on the server, or domain accounts in active directory if your server is a member of a domain, with varying degrees of access such as an administrator who should no longer be granted such permissions, another group to check is the remote desktop users group as this allows the user to remotely connect. This should be reviewed to avoid a possible security breach. Server access can be reviewed through the security log in event viewer on each server, or on the domain controller in a domain environment. You can check the members of important groups such as administrator, domain administrator, and remote desktop users.

Firewall rules reviewed in the last 6-12 months.
Firewall rules should also be reviewed from time to time to ensure that you are only allowing required inbound and outbound traffic. Requirements for a server change over time, as applications are installed and removed the ports that it is listening on may change, potentially introducing vulnerabilities, so it is important to restrict this traffic correctly. Ideally firewall changes should undergo a change request process, this will allow you to easily review who has put a particular change in place and their reasons for doing so.

Windows operating systems come with Windows Firewall installed and running by default, only inbound traffic is restricted while all outbound traffic is allowed out. You can test for ports that are responsive from another external server by using telnet to a specific port. You can also enable auditing events so that you can log and view denied traffic.

Confirm that users must change passwords.
User accounts should be configured to expire after a period of time, common periods are anywhere between 30-90 days. This is important so that the user password is only valid for a set amount of time before the user is forced to change it. This increases security because if an account is compromised it will not always be able to be used as the password will change to something different – access by an attacker will not be maintained through that account. It’s also worth checking that no users have been set to have their password never expire, for further information see here.

If your accounts are using active directory, this can be set centrally for the accounts there through group policy (see here for more information), otherwise you can set this on a per account basis locally on the server itself through the local users and computers console. However, this is not as scalable as using active directory because you need to implement the changes on all of your servers individually, which will take time and be harder to manage.

Backups

Backups and restores have been tested and confirmed to be working.
It is important to backup your servers in case of data loss. It is equally important to actually test that your backups work and that you can successfully complete a restore. Check that your backups are working on a daily or weekly basis – most backup software should be able to notify you if a backup task fails and this should be investigated and repaired as soon as possible.

It is a good idea to perform a test restore every few months or so to ensure that your backups are working as intended. This may sound time consuming but it is an important exercise. There are countless stories of backups appearing to work until all the data is lost; only then do people realize that they are not actually able to restore the data from backup.

You can backup locally to the same server, which is not recommended as you can lose the backup data if there is a problem at the server level. Alternatively and more preferably you can backup to an external location either on your network, or out on the Internet – this could be your own server or a cloud storage solution like Amazon S3. If backing up to the Internet it is important to consider the sensitivity of your data, you may want to encrypt the data before uploading it to a third party location for instance to keep it secure.

A simple and useful option could also be to enable shadow copies which allow you to easily revert files, though again like the local option this is not ideal, an offsite backup for important data should be maintained.

Monitoring

Monitoring has been checked and confirmed as working correctly.
If your server is used in production you most likely have it monitored for various services. It is important to check and confirm that this monitoring is working as intended and that it is reporting correctly so that you know you will be correctly alerted if there are any issues. It is possible that incorrect firewall rules may disrupt monitoring, or your server may be performing different roles now since the monitoring was originally set up and so may need to be monitored for additional services. You can monitor services and ports internally from your network by using something like a Nagios server, or with an external service such as Pingdom which is ideal for testing external facing services such as public websites as the health check traffic comes in over the Internet just like a normal users making it a good test.

Resource usage has been checked in the last month.
Resource usage is typically checked as a monitoring activity. It is, however, good practice to observe long term monitoring data in order to get an idea of any resource increases or trends which may indicate that you need to upgrade a component of your server so that it is capable of working under the increased load. This will depend on your monitoring solution, however you should be able to monitor CPU usage, free disk space, free physical memory and other variables for certain thresholds and if these start to trigger more often you will know to investigate further. Through Windows you can also define performance monitors to monitor various resources over time and present them as a graph, see here for more information.

Hardware errors have been checked in the last week.
Critical hardware problems will likely show up on your monitoring and be obvious as the server may stop working correctly. You can potentially avoid this scenario by monitoring your system for hardware errors which may give you a heads up that a piece of hardware is having problems and should be replaced in advance before it fails. Through Windows the best place to observe such events is through event viewer, typically under Windows logs > System, look for warnings and critical events.

File system maintenance

Unused applications have been removed in the last month.
You can save both disk space and reduce your attack surface by removing old and unused applications from your server, hardening it as there is less code available for an attacker to make use of. Checking for unused applications and removing them if not required should be done on a monthly basis. You can view the currently installed applications through Start > Control Panel > Programs > Programs and Features, or just searching for Programs and Features in start. It will display a list of everything installed, when it was installed and the size used. If you find anything suspicious that should not be there it should be removed and you should investigate how it got there immediately.

Disk integrity checked in the last month.
The traditional hard drive in a server typically has the most moving parts meaning it has the potential to have the most problems so it should be checked often. With the ‘chkdsk’ command you can scan the hard drive and check for a number of problems, you can do this in Computer by right clicking the drive, select properties > tools > check now. This is how you graphically run chkdsk and repair errors, otherwise you can use the command through command prompt.

NTFS introduced an online self-healing feature in Windows Server 2008 resulting in chkdsk not being needed as often, and since Windows Server 2012 corruption can be scanned for and fixed online with no down time. In previous versions of Windows Server before 2012 the file system volume would need to be taken offline in order to scan and repair, though you can run a scan only online without the repair option at any time. If you are running a server operating system that is older than 2012 you will need to schedule in the down time to run the repair if the chkdsk scan detects any faults on next boot.

Other general tasks

Event logs and statistics are being monitored daily or weekly.
Windows will report important events which can be viewed through the event viewer, these events should be checked at least weekly for warnings and critical issues. By default a server will log it’s events locally which means if you have a large number of servers you need to log into each one to check the events which is not very efficient. To make this task easier you can set up forwarded events where you choose one server to collect all of the events from other servers, allowing you to have one central location to store and view events via event viewer.

Regular scans are being run on a weekly/monthly basis.
In order to stay secure it is important to scan your server for malicious content. Windows Defender is a first line of defence which comes installed with some versions of Windows, however ideally you should be using a more comprehensive antivirus/anti-malware solution and scanning regularly, at least on a weekly basis during a period of time where there will be low resource usage so that the scan will not interfere with normal operations, for instance at 4am on Saturday if your servers are at their peak during the week. Don’t forget to ensure that your software also automatically updates every day or week to ensure that you are able to detect the latest threats.

Check server reliability every month.
Windows server comes with a reliability monitor that allows you to view overall system stability and view details about events that impact server reliability, it provides a stability index over a period of time to give you an idea of how reliably your server is running. Reliability monitor will display your reliability index from 1 to 10 over time, when there are program crashes or other problems the index will drop, the more stable it is over time with fewer problems the higher it will increase.

It’s an easy way to gain a quick overview regarding critical events that have happened on the server over time which can allow you to potentially make connections to events that may have started the problem, for instance you may have a lot of critical events after installing new software which can point you to investigating the software addition further.

Полное руководство по обслуживанию WSUS и Configuration Manager SUP

В этой статье данная статья посвящена некоторым распространенным вопросам об обслуживании WSUS для сред Configuration Manager.

Исходная версия продукта: Windows Servers, Windows Server Update Services, Configuration Manager
Исходный номер КБ: 4490644

Общие сведения

Часто возникают вопросы о том, как правильно запускать это обслуживание в среде Configuration Manager или как часто следует запускать это обслуживание. Нечасто добросовестным администраторам Configuration Manager не известно о том, что обслуживание WSUS следует запускать вообще. Большинство из нас просто настроили серверы WSUS, так как это необходимое условие для точки обновления программного обеспечения (SUP). После того как sup настроен, мы закроем консоль WSUS и даем вид, что она не существует. К сожалению, это может быть проблемой для клиентов Configuration Manager и общей производительности сервера WSUS/SUP.

Понимая, что это обслуживание необходимо сделать, вы хотите узнать, какое обслуживание необходимо сделать и как часто это необходимо сделать. Ответ заключается в том, что необходимо выполнять ежемесячное обслуживание. Обслуживание очень простое и не займет много времени для серверов WSUS, которые были хорошо обслуживаются с самого начала. Однако если с момента обслуживания WSUS прошло некоторое время, очистка может оказаться более сложной или отнимаемой в первый раз. В последующие месяцы это будет намного проще или быстрее.

Обслуживание WSUS при поддержке Configuration Manager текущей ветви версии 1906 и более поздних версий

Если вы используете текущую ветвь Configuration Manager версии 1906 или более поздней, рекомендуется включить параметры обслуживания WSUS в конфигурации точки обновления программного обеспечения на сайте верхнего уровня, чтобы автоматизировать процедуры очистки после каждой синхронизации. Она будет эффективно обрабатывать все операции очистки, описанные в этой статье, за исключением резервного копирования и переиндексации базы данных WSUS. По-прежнему следует автоматизировать резервное копирование базы данных WSUS, а также переиндексировать базу данных WSUS по расписанию.

Дополнительные сведения об обслуживании обновлений программного обеспечения в Configuration Manager см. в техническом обслуживании обновлений программного обеспечения.

Важные факторы

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

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

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

Обслуживание WSUS может выполняться одновременно на нескольких серверах одного уровня. При этом убедитесь, что один уровень был сделан, прежде чем перейти к следующему. Описанные ниже действия по очистке и переиндексации следует выполнить на всех серверах WSUS независимо от того, являются ли они серверами WSUS реплики. Дополнительные сведения об определении того, является ли сервер WSUS репликой, см. в подстроке «Отклонение».

Убедитесь, что во время обслуживания не синхронизируются СУУП, так как это может привести к потере уже сделанной работы. Проверьте расписание синхронизации SUP и временно установите его на ручной режим во время этого процесса.

Если имеется несколько S SUP основного сайта или центра администрирования, которые не совместно с SUSDB, рассмотрите сервер WSUS, который синхронизируется с первым SUP на сайте, как на уровень ниже сайта. Например, на моем сайте CAS есть два sup:

• Новый синхронизируется с Обновлением Майкрософт, это будет мой верхний уровень (уровень 1).
• Сервер с именем 2012 синхронизируется с New и будет рассмотрен на втором уровне. Его можно очистить одновременно со всеми другими серверами уровня 2, такими как один сервер SUP основного сайта.

Выполнение обслуживания WSUS

Основные действия, необходимые для надлежащего обслуживания WSUS:

Back up the WSUS database

С помощью нужного метода можно с помощью базы данных WSUS (SUSDB). Дополнительные сведения см. в подраздии «Создание полной резервной копии базы данных».

Создание пользовательских индексов

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

Если вы используете Current Branch Manager версии 1906 или более поздней версии, рекомендуется использовать Configuration Manager для создания индексов. Чтобы создать индексы, настройте параметр «Добавить некластерные индексы в базу данных WSUS» в конфигурации точки обновления программного обеспечения для наиболее верхнего сайта.

Если вы используете более старую версию Configuration Manager или автономные серверы WSUS, выполните следующие действия, чтобы создать настраиваемые индексы в базе данных SUSDB. Для каждой SUSDB это разовая процедура.

Убедитесь, что у вас есть резервная копия базы данных SUSDB.

Используйте SQL Management Studio для подключения к базе данных SUSDB так же, как описано в разделе «Переиндекска базы данных WSUS».

Запустите следующий сценарий для SUSDB, чтобы создать два пользовательских индекса:

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

Msg 1913, уровень 16, состояние 1, строка 4
Сбой операции, так как индекс или статистика с именем «nclLocalizedPropertyID» уже существует в таблице «dbo.tbLocalizedPropertyForRevision».

Переиндекска базы данных WSUS

Чтобы переиндексовать базу данных WSUS (SUSDB), используйте скрипт T-SQL базы данных WSUS.

Действия по подключению к SUSDB и выполнению переиндекски отличаются в зависимости от того, работает ли SUSDB в SQL Server или внутренней базе данных Windows (WID). Чтобы определить, где работает SUSDB, проверьте значение записи реестра на сервере SQLServerName WSUS, расположенном в HKEY_LOCAL_MACHINE\Software\Microsoft\Update Services\Server\Setup подмайке.

Если значение содержит только имя сервера или сервера\экземпляр, SUSDB работает на SQL Server. Если значение содержит строку или ##SSEE в ##WID ней, SUSDB работает в WID, как показано ниже:

Если SUSDB был установлен в WID

Если SUSDB был установлен в WID, SQL Server Management Studio Express необходимо установить локально для запуска сценария переиндекски. Вот простой способ определить, какую версию SQL Server Management Studio Express установить:

Для Windows Server 2012 или более поздних версий:

Перейдите C:\Windows\WID\Log в журнал ошибок, содержащий номер версии.

Посмотрите номер версии в how to determine the version, edition and update level of SQL Server and its components. Это значение указывает, Пакет обновления (SP) запущен WID. Включите уровень SP при поиске в Центре загрузки Майкрософт для SQL Server Management Studio Express.

Для Windows Server 2008 R2 или предыдущих версий:

• Откройте журнал последних ошибок C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\LOG с помощью Блокнота. Вверху будет номер версии (например, 9.00.4035.00 x64). Посмотрите номер версии в how to determine the version, edition and update level of SQL Server and its components. Этот номер версии указывает, Пакет обновления ли он работает. Включите уровень SP при поиске в Центре загрузки Майкрософт для SQL Server Management Studio Express.

После установки SQL Server Management Studio Express запустите его и введите имя сервера для подключения к:

• Если операцией является Windows Server 2012 или более поздней версии, используйте \\.\pipe\MICROSOFT##WID\tsql\query .
• Если ос более старая, чем Windows Server 2012, введите \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query .

Если при попытке подключения к SUSDB с помощью SQL Server Management Studio (SSMS) в WID возникают ошибки, похожие на следующие, попробуйте запустить SSMS с помощью параметра «Запуск от администратора».

Если SUSDB был установлен на SQL Server

Если SUSDB был установлен на полную SQL Server, запустите SQL Server Management Studio и введите имя сервера (и экземпляр при необходимости) при запросе.

Кроме того, для запуска скрипта переиндекски можно использовать совластику, которая sqlcmd называется .. Дополнительные сведения см. в переиндексной базе данных WSUS.

Выполнение скрипта

Чтобы запустить сценарий в SQL Server Management Studio или SQL Server Management Studio Express, выберите «Новый запрос», в paste the script in the window, а затем выберите «Выполнить». После завершения запроса на панели состояния будет отображаться сообщение об успешном выполнении запроса. А в области результатов будут содержаться сообщения, связанные с перестроенным индексом.

Отклонение замедераных обновлений

Отклонение замедераных обновлений на сервере WSUS для более эффективного сканирования клиентов. Перед отклонением обновлений убедитесь, что они развернуты и больше не нужны. Configuration Manager включает отдельную очистку, которая позволяет ему истечь срок действия замещаемого обновления на основе указанных критериев. Дополнительные сведения см. в следующих статьях:

Чтобы быстро определить количество переопределеных обновлений, можно выполнить следующий SQL запрос к базе данных SUSDB. Если количество переохаханых обновлений превышает 1500, это может вызвать различные проблемы, связанные с обновлением программного обеспечения как на стороне сервера, так и на стороне клиента.

Если вы используете текущую ветвь Configuration Manager версии 1906 или более поздней версии, рекомендуется автоматически отклодить переоценки обновлений, включив параметр «Отклодить просроченные обновления» в WSUS в соответствии с правилами supersedence в конфигурации точки обновления программного обеспечения для сайта верхнего уровня.

При использовании этого параметра можно увидеть, сколько обновлений было отклонено, просмотрев файл WsyncMgr.log после завершения синхронизации. Если вы используете этот параметр, вам не нужно использовать сценарий, описанный далее в этом разделе (вручную или путем настройки в качестве задачи для его запуска по расписанию).

Если вы используете автономные серверы WSUS или более старую версию configuration Manager, можно вручную отклонить переоправленные обновления с помощью консоли WSUS. Вы также можете запустить этот сценарий PowerShell. Чтобы скачать сценарий, щелкните ссылку правой кнопкой мыши и выберите «Сохранить целевой объект как». Скачайте сценарий, удалите расширение файла и .txt сохраните файл с .PS1 расширением.

Этот сценарий предоставляется как есть. Перед использованием в производственной лаборатории его необходимо полностью протестировать в лаборатории. Корпорация Майкрософт не дает никаких гарантий относительно использования этого сценария. Сначала запустите сценарий с параметром, чтобы получить сводку о том, сколько переоценных обновлений -SkipDecline будет отклонено.

Если для Configuration Manager установлено немедленное истечении срока действия замеченных обновлений (см. ниже), сценарий PowerShell можно использовать для отклонения всех переоценки обновлений. Это следует сделать на всех автономных серверах WSUS в иерархии Configuration Manager или WSUS.

Вам не нужно запускать сценарий PowerShell на серверах WSUS, которые настроены как реплики, например на дополнительных серверах. Чтобы определить, является ли сервер WSUS репликой, проверьте параметры источника обновления.

Если в Configuration Manager не настроено немедленное истечении срока действия обновлений, сценарий PowerShell должен быть запускаться с периодом исключения, который соответствует параметру Configuration Manager в течение нескольких дней с истекшим сроком действия замеченных обновлений. В этом случае прошло бы 60 дней, так как свойства компонента SUP настроены на ожидание за два месяца до истечения срока действия замеченных обновлений:

Следующие командные строки иллюстрируют различные способы запуска сценария PowerShell (если сценарий работает на сервере WSUS, его можно использовать в качестве LOCALHOST SERVERNAME фактического):

Запуск скрипта с a и сбором сведений об обновлениях на сервере WSUS и о том, сколько обновлений можно -SkipDecline -ExclusionPeriod 60 отклодить:

Запуск сценария с помощью -ExclusionPeriod 60, чтобы отклонить переоценки обновлений старше 60 дней:

Индикаторы вывода и хода выполнения отображаются во время выполнения сценария. Обратите внимание SupersededUpdates.csv, который будет содержать список всех обновлений, отклоненных сценарием:

Если при попытке использования вышеуказанного сценария PowerShell для отклонять переоценки обновлений возникают проблемы, см. раздел «Время работы сценария Decline-SupersededUpdatesWithExclusionPeriod.ps1 при подключении к серверу WSUS» или ошибка 401 при запуске для устранения неполадок.

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

Запуск мастера очистки сервера WSUS

Мастер очистки WSUS Server предоставляет возможности для очистки следующих элементов:

• Неиспользованые обновления и обновления (также известные как устаревшие)
• Компьютеры, не обращающиеся к серверу
• Нежелательные файлы обновления
• Обновления с истекшим сроком действия
• Переудержаные обновления

В среде Configuration Manager компьютеры, не обращающиеся к серверу и нежелательные файлы обновлений, не имеют значения, так как Configuration Manager управляет контентом и устройствами обновления программного обеспечения, если только в параметрах синхронизации обновлений программного обеспечения не выбраны параметры создания всех событий отчетов WSUS или создания только событий отчетов о состоянии WSUS. Если настроен один из этих параметров, следует рассмотреть возможность автоматизации очистки сервера WSUS для очистки этих двух вариантов.

Если вы используете Current Branch Manager версии 1906 или более поздней версии, включение отклонимые обновления с истекшим сроком действия в WSUS в соответствии с правилами supersedence обрабатывает отклонение обновлений с истекшим сроком действия и переоценки обновлений на основе правил суперсхемы, указанных в Configuration Manager. Включение параметра «Удалить устаревшие обновления из базы данных WSUS» в Configuration Manager текущей ветви версии 1906 позволяет очищать неиспольвленные обновления и их изменения (устаревшие). Рекомендуется включить эти параметры в конфигурации точки обновления программного обеспечения на сайте верхнего уровня, чтобы позволить Configuration Manager очистить базу данных WSUS.

Если ранее вы никогда не очищали устаревшие обновления из базы данных WSUS, время для этой задачи может и выйти из эксплуатации. Дополнительные сведения можно просмотреть в журнале WsyncMgr.log и вручную запустить сценарий SQL, указанный в HELP! My WSUS has been running for years without ever having maintenance done and the cleanup wizard keeps timing out once, which would allow subsequent attempts from Configuration Manager to run successfully. Дополнительные сведения о очистке и обслуживании WSUS в Configuration Manager см. в документы.

Для автономных серверов WSUS или при использовании более старой версии Configuration Manager рекомендуется периодически запускать мастер очистки WSUS. Если мастер очистки сервера WSUS никогда не запускался, а WSUS уже некоторое время работает, время очистки может и выйти из игры. В этом случае сначала переиндексуются с помощью шага 2 и шага 3, а затем запустите очистку, проверив только неиспользимые обновления и вносимые изменения.

Если вы никогда не запускали мастер очистки WSUS, для запуска очистки с неиспользимными обновлениями и внесения изменений может потребоваться несколько проходов. Если время работы не завершается, запустите его еще раз, пока не завершится, а затем запустите каждый из остальных параметров по одному. Наконец, сделайте полный проход со всеми проверенными вариантами. Если по-прежнему происходят периоды времени, см. SQL Server help! My WSUS has been running for years without ever having maintenance done and the cleanup wizard keeps timing out. Выполнение мастера очистки сервера может занять несколько часов или SQL или несколько дней.

Мастер очистки сервера WSUS запускается из консоли WSUS. Он находится в меню «Параметры», как показано ниже:

После того как она сообщает о количестве элементов, которые она удалила, очистка завершается. Если эти сведения не возвращаются на сервере WSUS, можно предположить, что время очистки было иным. В этом случае вам потребуется запустить его снова или использовать альтернативу SQL .

После того как переустановленные обновления будут отклонены, для обеспечения лучшей производительности необходимо повторно переиндексовать SUSDB. См. раздел «Переиндекска базы данных WSUS» для получения соответствующих сведений.

Устранение неполадок

Справка! My WSUS has been running for years without ever having maintenance done and the cleanup wizard keeps timing out!

Существует два разных варианта:

Переустановить WSUS с новой базой данных. Существует ряд предостеречений, связанных с этим, включая длину начальной синхронизации и полные проверки клиента на SUSDB, а также разнонаправленные проверки.

Убедитесь, что у вас есть резервная копия базы данных SUSDB, а затем запустите переиндексирование. После этого выполните следующий сценарий в SQL Server Management Studio или SQL Server Management Studio Express. После завершения выполните все вышеперечисленные инструкции по обслуживанию. Это последний шаг является необходимым, так как хранимая процедура удаляет только неиспользованые обновления spDeleteUpdate и обновления.

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

Время Decline-SupersededUpdatesWithExclusionPeriod.ps1 при подключении к серверу WSUS или ошибка 401 возникает при запуске

Если при попытке использовать сценарий PowerShell для отклония заметивных обновлений возникают ошибки, можно запустить альтернативный сценарий SQL для SUDB.

Если Configuration Manager используется вместе с WSUS, проверьте правила > supersedence свойств компонента точки обновления программного обеспечения, чтобы узнать, как быстро истекает срок действия переоценки обновлений, например сразу же или после X месяцев. Заметьте этот параметр.

Если вы еще не вернули базу данных SUSDB,сделайте это, прежде чем дальнейшем.

Используйте SQL Server Management Studio для подключения к SUSDB.

Запустите следующий запрос. Номер 90 в строке, включаемой, должен соответствовать правилам суперсемейства на шаге 1 этой процедуры и правильному числу дней, соответствующему количеству месяцев, задамому в правилах DECLARE @thresholdDays INT = 90 суперсемейства. Если срок действия этого значения истекает немедленно, SQL запросе @thresholdDays должно быть установлено нулевое значение.

Чтобы проверить ход выполнения, отслеживайте вкладку «Сообщения» в области результатов.

Что делать, если я знаю, что мне нужно одно из обновлений, которое я отклонил?

Если вам нужно одно из этих отклоненных обновлений в Configuration Manager, вы можете вернуть его в WSUS, щелкнув правой кнопкой мыши обновление и выбрав «Утвердить». Измените утверждение на «Не утверждено», а затем повторно заглянив в SUP, чтобы вернуть обновление.

Если обновления больше нет в WSUS, его можно импортировать из каталога обновлений Майкрософт, если срок его действия еще не истек или он был удален из каталога.

Автоматизация обслуживания WSUS

Если вы используете Configuration Manager версии 1906 или более поздней версии, автоматизировать процедуры очистки, включив параметры обслуживания WSUS в конфигурации точки обновления программного обеспечения сайта верхнего уровня. Эти параметры обрабатывают все операции очистки, выполняемые мастером очистки сервера WSUS. Однако по-прежнему следует автоматически сделать это по расписанию и переиндексировать базу данных WSUS.

Задачи обслуживания WSUS можно автоматизировать при условии, что в первую очередь выполнены некоторые требования.

Если вы никогда не запускали очистку WSUS, первые две очистки необходимо выполнить вручную. Вторая очистка вручную должна быть запускаться через 30 дней после первой, так как для некоторых обновлений и обновлений требуется 30 дней. Есть определенные причины, по которым не нужно автоматизировать процесс до второй очистки. Первая очистка, вероятно, будет работать дольше обычного. Поэтому вы не можете оценить, сколько времени обычно займет это обслуживание. Вторая очистка — это гораздо лучший показатель того, что нормально для компьютеров. Это важно, так как необходимо выяснить, сколько времени занимает каждый шаг в качестве базового (мне также нужно добавить 30-минутное пространство), чтобы вы могли определить время для расписания.

Если у вас есть серверы WSUS ниже, сначала необходимо выполнить обслуживание на них, а затем выполнить последующие серверы.

Чтобы запланировать переиндексировать SUSDB, потребуется полная версия SQL Server. Внутренняя база данных Windows (WID) не может запланировать задачу обслуживания, хотя SQL Server Management Studio Express. При этом в случаях, когда используется WID, можно использовать планирщик задач с SQLCMD упомянутым ранее. Если вы будете переходить по этому маршруту, важно не синхронизировать серверы WSUS и SPS в этот период обслуживания! В этом случае, возможно, нижестоячие серверы просто повторно засвещают все обновления, которые вы только что пытались очистить. Я запланируйте это на ночь перед синхронизацией AM, поэтому у меня есть время проверить ее перед запуском синхронизации.

Необходимые и полезные ссылки:

Сценарий очистки WSUS

Настройка задачи очистки WSUS в планщике задач

Как упоминалось ранее, если вы используете Current Branch Manager версии 1906 или более поздней версии, автоматизировать процедуры очистки, включив параметры обслуживания WSUS в конфигурации точки обновления программного обеспечения сайта верхнего уровня. Для автономных серверов WSUS или более старых версий Configuration Manager можно продолжать использовать следующие действия.

Запись блога «Сценарий выходных дней», упомянутая в предыдущем разделе, содержит основные указания и устранение неполадок для этого шага. Тем не менее, я пою вас по этой процедуре на следующих шагах.

Откройте планировать задачи и выберите «Создать задачу». На вкладке «Общие» установите имя задачи, имя пользователя, с помощью которого вы хотите запустить сценарий PowerShell (большинство пользователей используют учетную запись службы). Выберите «Выполнить» независимо от того, вошел ли пользователь в систему, и при желании добавьте описание.

На вкладке «Действия» добавьте новое действие и укажите программу или сценарий, которые нужно запустить. В этом случае необходимо использовать PowerShell и указать ps1-файл, который мы хотим запустить. Можно использовать сценарий очистки WSUS. Этот сценарий выполняет параметры очистки, не выполняемые Configuration Manager текущей ветви версии 1906. Их можно отменить, если вы используете автономный WSUS или более старую версию Configuration Manager. Если вы хотите получить журнал, вы можете изменить последнюю строку скрипта следующим образом:

При экономии вы получите fYI/предупреждение в планщике задач. Это предупреждение можно игнорировать.

На вкладке «Триггеры» запланировать расписание на один раз в месяц или по любому расписанию. Опять же, необходимо убедиться, что WSUS не синхронизируется в течение всего времени очистки и переиндекски.

Установите любые другие условия или параметры, которые вы также хотите изменить. При сохранение задачи может возникнуть запрос учетных данных пользователя «Запуск как».

Эти действия также можно использовать для настройкиDecline-SupersededUpdatesWithExclusionPeriod.ps1 запуска каждые три месяца. Обычно я задаю этот сценарий для запуска до других действий по очистке, но только после запуска вручную и успешного завершения. Я запускаю в 12:00 утра в первое воскресенье каждые три месяца.

Настройка переиндекски SUSDB для WID с помощью SQLCMD и планатора задач

Сохраните скрипт базы данных WSUS в качестве SQL-файла (например, SUSDBMaint.sql).

Создайте базовую задачу и придайте ей имя:

Запланировать запуск этой задачи примерно через 30 минут после завершения очистки. Очистка будет запущена в 1:00 каждое первое воскресенье. Для запуска требуется около 30 минут, и я хочу дать ему еще 30 минут, прежде чем начинать переиндекску. Это означает, что я планю эту задачу на каждое первое воскресенье в 2:00, как показано ниже:

Выберите действие для запуска программы. В поле «Программа/сценарий» введите следующую команду: Файл, указанный после параметра, является путем к SQL -i сценария, сохраненного на шаге 1. Файл, указанный после параметра, находится в расположении -o журнала. Пример:

«C:\Program Files\Microsoft SQL Server\110\Tools\Binn\SQLCMD.exe» -S \\.\pipe\Microsoft##WID\tsql\query -i C:\WSUS\SUSDBMaint.sql -o c:\WSUS\reindexout.txt

Вы получите предупреждение, аналогичное тому, что вы получили при создании задачи очистки. Выберите «Да», чтобы принять аргументы, а затем выберите «Готово», чтобы применить:

Вы можете протестировать сценарий, принудительно запустить его и просмотреть журнал на ошибки. Если у вас будут проблемы, журнал покажет, почему. Обычно при сбойе у учетной записи, запускаемой задачей, нет соответствующих разрешений или служба WID не запущена.

Настройка базовой задачи планового обслуживания в SQL для SUSD, не относяхся к WID

Для создания планов обслуживания и управления ими необходимо быть SQL Server в качестве SQL Server.

Откройте SQL Server Management Studio и подключите его к экземпляру WSUS. Разйдите «Управление», щелкните правой кнопкой мыши планы обслуживания и выберите «Новый план обслуживания». Придайте плану имя.

Выберите subplan1 и убедитесь, что ваша панели инструментов находится в контексте:

Перетащите задачу Execute T-SQL Statement Task:

Щелкните его правой кнопкой мыши и выберите «Изменить». Скопируйте и в paste скрипт переиндексировать WSUS, а затем выберите «ОК»:

Запланировать запуск этой задачи примерно через 30 минут после завершения очистки. Очистка будет запущена в 1:00 каждое первое воскресенье. Для запуска требуется около 30 минут, и я хочу дать ему еще 30 минут перед началом переиндекски. Это означает, что я планю эту задачу запускать каждое первое воскресенье в 2:00.

При создании плана обслуживания также можно добавить в план резервную копию SUSDB. Как правило, сначала я свою их, а затем переиндексую. Это может добавить больше времени в расписание.

Готовое решение

При запуске в иерархии необходимо выполнить очистку WSUS снизу вверх. Однако при использовании сценария для отклонения переоценки обновлений запуск следует выполнить сверху вниз. Отклонение замеющихся обновлений — это на самом деле дополнение к обновлению, а не удаление. В этом случае фактически добавляется тип утверждения.

Так как синхронизацию невозможно выполнить во время фактической очистки, рекомендуем запланировать или завершить все задачи за одну ночь. Затем проверьте их завершение с помощью ведения журнала следующим утром, перед следующей запланированной синхронизацией. Если что-то не удалось, обслуживание можно перепланить на следующую ночь после того, как будет обнаружена и устранена проблема.

Эти задачи могут выполняться быстрее или медленнее в зависимости от среды, и расписание должно отражать это. Надеемся, что они быстрее, так как моя лабораторная среда, как правило, немного медленнее, чем обычная производственная среда. Я немного агрессивный по отношению к времени сценариев отклонинга. Если уровень 2 перекрывает уровень 3 на несколько минут, это не приведет к проблеме, так как синхронизация не запланирована.

Если не синхронизировать, отклонение не будет случайно поступать на серверы WSUS реплики Tier3 с уровня 2. Я вернул себе дополнительное время между отклонением уровня 3 и очисткой уровня 3, так как я определенно хочу убедиться, что сценарий отклониваем завершается, прежде чем запускать очистку.

Возникает распространенный вопрос: так как я не синхронизуюсь, почему бы мне не выполнить все очистки и переиндексы одновременно?

Ответ заключается в том, что вы, вероятно, сможете, но я не буду. Если моей коллеге во всем мире необходимо выполнить синхронизацию, с помощью этого расписания я бы свести к минимуму риск потерянных обновлений в WSUS. И я могу запланировать его повторное выполнение на следующую ночь.

Время	Уровень	Задачи
12:00	Уровень 1 —отклонение
12:15 AM	Уровень 2 —отклонение
12:30	Tier3-Decline
01:00	Очистка WSUS уровня 3
02:00	Переиндекска уровня 3	Очистка WSUS уровня 2
03:00	Tier1-Cleanup	Переиндекска уровня 2
04:00	Переиндекска уровня 1

Если для обслуживания WSUS вы используете Current Branch Manager текущей версии 1906 или более поздней версии, Configuration Manager выполняет очистку после синхронизации с помощью верхней версии. В этом сценарии можно запланировать выполнение заданий резервного копирования и переиндексации базы данных WSUS до настроив расписание синхронизации, не беспокоясь о других действиях, так как Configuration Manager будет обрабатывать все остальное.

Дополнительные сведения о обслуживании SUP в Configuration Manager см. в следующих статьях: