Discussion of Windows 2003 Post-Install Actions

In the Windows 2003 Post-Install Actions recipe, we documented multiple procedures we like to take after the basic installation of a standalone Windows 2003 server. Here we discuss the thinking behind those procedures.

• Take a snapshot (procedure)
  • Taking a VMware snapshot before performing administrative actions on your servers is pretty much always a good idea. This allows you to revert to the snapshot if problems occur. Think of it as a nearly instant backup.
• Login and increase screen resolution (procedure)
  • This action is pretty basic – mainly a convenience to the system administrator.
• Check Event Logs (procedure)
  • While many sysadmins don’t bother with server logs until there are problems, I strongly believe in regular proactive checking of event logs, and resolution errors found there. This is a way to stay ahead of the curve, and out from behind the 8-ball! I would not expect there to be any problems on a newly installed system – but I check anyway, for my own peace of mind.
• Setup Security Auditing (procedure)
  • We often hear sysadmins asking “how can I check whether $someperson did $somebadthing on my servers?” The answer to this question is usually a review of the Security logs. However Windows does not by default log very many actions to the Security log – the sysadmin must proactively configure more verbose security logging before the events occur which he/she may later be interested in.
  • In the recipe, we demonstrate the configuration of Windows auditing to log as much as it possibly can – success and fail events for all audit types. Further, we configure object access logging for all file objects on all drives. This will create a massive and, to some, rather dauntingly ‘noisy’ Security log.  However, it’s difficult to predict what you’ll need from the Security log in the future, and disk space is cheap. So we advocate logging everything.
  • This raises the question of how long to keep all those logs! This depends on many factors: your system administration style, the needs of other members of your team, corporate policy, and legal/regulatory considerations. A future recipe will likely discuss these concerns in greater depth, but for this recipe, we have capped the security log at 100 megabytes. Once it reaches that size, it will discard the oldest entries to make room for new ones. It should be noted that this does not guarantee an specific calendar retention time – on a mostly-idle server, 100MB could hold months worth of log data. But on a very busy server, it might only be a few hours worth! So please bear in mind the possibility of having to revisit your security auditing practices in the future.
• Activate Windows (procedure)
  • Windows requires activation, so we perform this quick and easy procedure.
• Enable Remote Administration via Terminal Services (procedure)
  • While the vSphere client is acceptable for most administration work, many sysadmins prefer to use Remote Desktop (also known as RDP). It’s generally more performant than the vSphere client, and has a good security reputation.
  • However, until we’ve performed security updates, the server will refuse all network connections. So we’ll be using the vSphere console client for our security updating recipe as well.
• Verify Devices Installed Correctly (procedure)
  • Like reviewing the Event Logs, this is a good proactive measure to take.
• Install the VMware tools (procedure)
  • The VMware tools certainly make the vSphere client easier to use: the mouse becomes more responsive, more display resolutions become available. But there are really two key reasons to install the VMware tools:
    • They allow VMware to perform graceful startup and shutdown of the guest OS, either at the sysadmin’s command via vSphere, or automatically, when the VMware host system is starting up, shutting down, or going into mainteinance mode.
    • They allow time synchronization between the guest and the VMware host. Accurate timekeeping is a complex and thorny issue for any virtualized guest system, and the VMware tools time sync is one easy way to keep the guest system clock relatively in tune with real time.

Do you agree/disagree with these procedures? Have more to add? Want to share your wisdom? Add your comments below!