Windows server 2008 maintenance checklist

Where 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 that they will be compatible with any other packages or software 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. From here you can check for and install updates, and select if they should download and install automatically. This is enabled by default and the recommended option.

It may not always be possible to have production servers rebooting whenever there are updates out of hours so you may need to disable these and schedule in updates and reboots as required. If you have numerous servers you can configure Windows updates through group policy instead of locally on each server. Lots of web applications may well also have third party plugins installed which can be coded by anyone, potentially having many security vulnerabilities. As such it is crucial 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. 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 viewers 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 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.

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. User accounts should be configured to expire after a period of time. Common periods are anywhere between 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 is 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 through group policy. Otherwise, you can set this on a per account basis locally on the server itself through local users and computers. 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.

It is important to back up 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 should be investigated. 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 well worth it. There are countless stories of backups appearing to work until all the data is lost; only then do people realise that they are not actually able to restore the data from backup. You can back up locally to the same server, which is not recommended, or you can back up 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 or Acronis backup for Windows Server.

A simple and useful option could also be to enable shadow copies, which allow you to easily revert files. 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 you know you will be correctly alerted if there are any issues.

It is possible that incorrect firewall rules may disrupt monitoring, or that your server may be performing different roles now and so may need to be monitored for additional services. If you have a server monitored already it is also very easy to add or remove monitors to fit the current role of the server so that you can monitor the required services. Resource usage is typically checked as a monitoring activity.

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. 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.

Other applications have been updated within the last week. 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. 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 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 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. 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 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 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.