Sergey Nivens - Fotolia
Server and systems documentation is a vital part of IT management. But the documentation itself can pose a tedious, error-prone manual process for many smaller IT shops. Let's look at some ideas and considerations that might help shops automate server documentation tasks.
Q. What information should a server documentation or inventory process capture?
The information that is discovered and captured in a documentation process can vary significantly depending on the size, complexity and maturity of the IT environment, as well as any underlying business requirements.
Just consider the scope of information that can be collected from server hardware. For each server "box," organizations can collect a serial number, manufacturer, model and an asset tag assigned to the box. Most organizations delve inside each box to document the server's motherboard manufacturer and model, the installed processor configuration -- including clock speed and core count -- the total physical memory installed, the motherboard's BIOS or firmware manufacturer and version, and the System Management BIOS version. The organization may also collect information on expansion devices such as Fibre Channel controllers, network adapters and graphics processors.
If the server contains magnetic or solid-state disk storage, you should also detail each disk's ID, description, manufacturer, model, serial number, capacity, sector/track layout, SCSI details and interface type.
Once you collect the physical and hardware details, document major operating system layers that run on top of each server's hardware. For example, if the box is virtualized, the inventory should include the virtualization vendor, hypervisor product and hypervisor version, such as VMware ESXi 6.5. It is unlikely for documentation to detail each VM because they're intended to be fluid and abstracted from the underlying hardware.
However, the system management VM, or the physical machine, has an OS that you should document for that server. OS details can include the OS name, version, build details and any service packs or major updates installed. Windows Server platforms typically capture additional details such as the OS serial number, PowerShell settings, workgroup or domain memberships and roles, Registry details, date and time configuration, and .NET Framework setup information.
Q. Should I use homemade scripts or a professional tool to automatically capture server configurations?
It is possible to use custom scripts, such as Windows Server PowerShell, to perform system inventories and other tasks. One simple example is the Windows System Inventory.ps1 script posted on Microsoft TechNet. It's important to verify that the script works on the platform you use and that it collects the information the business needs. It may be possible to update or alter an existing script to add more inventory or enhance reporting behaviors, or even write new PowerShell scripts from scratch.
You don't need an outside tool, but writing and modifying scripts takes time and effort that can be better spent on other IT projects. Scripts are usually best for smaller organizations with limited IT deployments. When an IT environment includes too many diverse systems to document with a single or even a suite of related scripts, or you must include non-Windows systems in the server documentation process, invest in a third-party tool such as ManageEngine's Device Information tool or CENTREL Solutions' Network Documentation tool. These tools are designed for inventory/configuration discovery, recording and reporting. Implement an outside tool to provide better reporting and free IT staff from time-consuming script maintenance.
Q. Should we use version control on server configurations?
A common fear for IT professionals is "unintended consequences," such as making uncontrolled or poorly managed changes to systems that result in accidental disruptions to other systems.
A simple example here is a Windows Server update. Windows includes tools that can easily download and install patches as they are released. But patching one thing can inadvertently break something else, resulting in time-consuming troubleshooting, sub-optimal workarounds or outright rollbacks from backups. This is why so many organizations rely on version control services like WSUS for more controlled and centralized patch management in a Windows environment.
Use server documentation to support security or security audits
IT professionals must be able to determine the security posture of each system and document it. A documentation tool, especially one with automation capabilities, can typically discover and record a wealth of security-related issues organized by individual machine or domain.
For example, SSL certificate information can capture details including each name, issuer, public key, serial number, signature algorithm, version and expiration. A range of certificate stores can then be audited including personal certificates, intermediate/trusted root/third-party certification authorities, trusted publishers, and trusted users. This allows IT administrators to quickly understand what SSL certificates are in force and verify that each meets the required version level.
Documentation tools can automatically record and audit user rights assignments involving the privileges assigned to user accounts. Security reporting can also summarize password policies that define password complexity and account lockout behaviors for each system.
To avoid these unintended consequences, implement comprehensive change management. Change management functionality, such as Microsoft's desired state configuration, ensures each hardware or software element exists in a known configuration and cannot be substantially altered from that known state. And, all changes and change attempts are logged for auditing.
Not only can proper change management prevent unauthorized changes, it can also ease troubleshooting when changes result in unanticipated problems. IT staff can easily identify the changes that occurred and undo those changes with minimal amounts of time and troubleshooting. Discovery and documentation platforms are central elements of any change management protocol, helping IT staff to see any differences between what should be running and what actually is running. Those differences are where the problem likely resides. But it's almost impossible to achieve that kind of definitive clarity without a comprehensive documentation tool.
Tools and processes are key assets for system and server documentation, but implement them into the data center slowly. Evaluate and test them carefully first, and then systematically phase them into IT operations with adequate training for all IT staff. Share the documentation with management, and protect the documents against unauthorized changes to help meet compliance requirements.
Know the tools and practices to master IT documentation
Don't allow documentation to hold IT hostage
Documentation is a key responsibility of sys admins