Steps to Upgrading Your Server
Last updated on August 18, 2021
At some point, servers must undergo system upgrades. To avoid potential problems, system administrators must plan for possible errors whenever possible.
Information
It is important to obtain as much information as possible on the server, and to make sure this information is always close at hand. More importantly, you must ensure the information at hand is well-understood; if the server is running a 64-bit OS, you must install software that is operational on a 64-bit OS, requiring hardware with 64-bit drivers. I would recommend a log file be kept for each server, allowing all updates, upgrades and patches to be recorded in this file. This log file should naturally be kept on another machine as well, in case the server goes down.
You may wish to include the contacts of the server’s suppliers in the log file; before an update, the document can be printed and kept within reach. The document can be updated with critical information, such as versioning and installation dates.
This document should always be close at hand before starting your upgrade. One way to facilitate this process is to label each server with a tag, which includes all relevant information, including the server’s name, OS version, and important hosted services.
Upgrading the Operating System
Consistently check that all drivers are available for your new OS. If the OS architecture has changed, such as when switching from a 32-bit Os to a 64-bit, ensure that all drivers are available in 64-bit. This can be done by checking the server manufacturer’s site.
Never install the OS for the first time on your server; rather, run the installation and test the OS multiple times on other machines before deploying it to the server. Test the software which will be installed on the server with the new OS on a testing machine before server deployment.
One Change At a Time
You must plan to execute a single change at a time. Many administrators agree on the fact that a server should be restarted as few times as possible. However, I disagree; I prefer an additional reboot if it allows me to monitor all the effects of a single change.
After each change, all critical services must be tested. Make sure all data is intact, with no new errors reported in the logs. Check third party applications’ logs as well, and monitor the logs for the whole next week. If you have multiple changes, but a limited amount of time, plan a least a day between each update; the longer the break, the better.
Power Sources
Make sure, whenever possible, that the server is disconnected from local power sources. For blade servers or a simple computers alike, always make sure that there is no power running across the board, especially when upgrading ram modules.
Usually, there are indicators (LEDs) on the motherboard, showing that power is still present across the board; these must be switched off.
New Hardware Performance
Sometimes hardware does perform better using the most recent driver versions. Alternatively, new drivers may still have unresolved bugs. To safely use new drivers, open a support ticket with the hardware provider, and ask them concerning known issues for a particular OS and hardware version. You may wish to check their forum for professionals facing similar issues with their configurations.
Hardware-Specific Data
Some machines require specific hardware or software (matched memory modules, for example) to increase bandwidth and data transfers. Ensure that your motherboard has a list of supported chips and modules, and that you are using the specific hardware or software required for your machine.
Cost vs. Performance
Although cheap unbranded hardware appears to operate similarly to expensive branded hardware, this is typically not the case. Branded hardware tend to pass more rigorous tests than cheaper editions. Support is therefore critical in cases where new software or hardware is going to be installed.
Cheaper hardware usually uses cheaper components, and may use slower chips, inhibiting data transfers. Quality hardware may also last longer, and many companies may offer 24-hour product guarantees in case of hardware failure. Hardware must therefore be chosen carefully, especially memory modules and raid controllers.
Backups
Executing a backup is important, even when the server is operating normally. This is highly important; all files must be saved on another server, and if necessary, to a hard copy. This is critical, as there is no guarantee that the OS will boot up after a restart.
Disk images allow for very useful and quick recovery; although requiring significant resources, this method is the fastest approach to server recovery.
Update Planning
Unplanned changes are sometimes necessary, but whenever possible, planned changes are recommended. It is important to create a document with planned steps listed; even for simple updates, ensure that you know what might be affected, and check whether the server would need rebooting. Try the update on a dummy machine first, writing down all the steps required. Use dry-runs for the procedure more than once, consulting your colleagues when possible, to prevent errors.
Search Online
Always perform a search on the Internet for the software and hardware you are trying to install. People may have found problems which you might encounter during your installation. If new software is going to be installed, make sure that it was tested with your version of OS. Make a list of ports it might use, and run a netstat for any port conflicts that may arise. If you have a firewall, configure it before installation begins, and document all findings. If solutions are found online, these should be printed and kept close at hand, for later use.
Monitor Logs
Begin checking logs at least a week before planned updates, recording all errors and warnings reported by the server. Monitor the logs for at least a week after updates, as some problems appear far after the initial installation.
Additional Settings
Proactively plan any additional settings you might use when installing new software or hardware. For example, you may wish to increase the load on your newly installed hard-drive. A new hard disk may reduce access from other disks, thus preventing data movement across disks. Any page files in use should be moved to a disk with a lighter load; use the Windows Performance Monitor to check for system bottlenecks.
Testing Drivers on Other Machines
When installing new software and hardware, it is prudent to test it on another machine before deploying it in production. The same OS, software and drivers should be tested, to spot all potential production problems.
Testing on Virtual Machines
Having a virtual machine clone of your production machine is recommended, as some have services which can be cloned. Therefore, always test any updates or software patches on your virtual testing machine.
Updating 2X Software Products
Upgrading your 2X software is extremely straightforward. As mentioned above, always test upgrades on another server, avoiding initial deployment to production machines.
If you have a complicated network, with group policies and firewalls, reproduce your network in a smaller testing environment, with 2X Software products installed. Ensure all functions are working, and test all critical features, such as Universal Printing and Scanning and application filtering.
Routinely create backups of your 2X product settings, export your settings and save them at another site. For the 2X ApplicationServer and 2X VirtualDesktopServer, this is done using “File > Export” to export your settings. Importing settings can follow the same procedure.
Ensure no users are using the software during backups, as some services will be restarted when updates are applied. Clear logs before installing, as this will assist in spotting errors when upgrading.
With the 2X Thin Client OS, ensure all thin clients can boot successfully, and that all features are working before deployment to production. If having problems, open a ticket with the 2X Support team, and report the issue.
No uninstalling is needed to upgrade 2X products; a simple installation over the existing version is sufficient, with a server restart to maintain existing services.