In part six of this series we started a three article cycle looking at the lifecycle of a server and at the associated processes that accompany each phase.  We continue here in part 7, with looking at the Retirement process.

Why a Retirement Process?

                Deployment processes seem almost obvious; why would a retirement process be needed?  Can't a server just be shutdown and thrown away?   Well, for a tightly-managed production environment, a server retirement is not as simple as shutting down a server and stowing the hardware.   Monitoring systems are still looking for the server and its services.  Backups are still scheduled to run.  Historical data still remains on tapes and on SANs.  Should this information be retained?  And if so, for how long?

Without a Retirement Process:

                Without a standardized process, the system administration team goes ahead and shuts down the server.  Alerts go off, pagers are notified calls are made to stop the monitoring and submit the backup tapes to the scratch pool.  Once the administrator clarifies all of this, he goes to reformat the drives in order to repurpose the server.  Right after he has dropped the RAID array and started the rebuild, he gets a phone call - it is the owner of the application that was on the server.   The application owner forgot to tell the administration team, but he needs the server up for another month - he has not gotten everything off yet.   With the production application down and drives erased, the server administrator gets in trouble for not quadruple-checking that the application administrator had done his job.

Process:

                The process depends on your organization.  I'd recommend steps similar to the following.

                When the server support team receives a ticket or communication indicating that a server is to be retired, the server  retirement process must be followed.  For internal users and a external users that are familiar with the process, direct submission of the retirement request is allowed.  For all others, a meeting should be scheduled to review the document.  The basic procedure is as follows:

1. Initial Communication - Client Requests Server retirement
2. Server Retirement Request Meeting - Administrator meets with client to complete server retirement request
3. Request Review & Approval - Server retirement request is reviewed, amended, if required and approved.
4. Retirement Scheduled - A retirement date is chosen and a request placed to remove the server to the data center.  This date must be reviewed and approved by data center management.  A change / downtime request must be completed for this change, regardless of the server’s production status or support hours.
5. Backup Confirmation - The retiring administrator must confirm the existence of a valid server backup prior to taking any action toward retirement.  Backup services should be requested to be suspended on the eve of the scheduled server shutdown.  Backups are to be retained for 1 year after shutdown.
6. Decommissioning requests- The server administrator handling the retirement should review the New Server checklist and remove the server from the resources to which it was added. (Nagios, Altiris, etc.) 
7. Pre-Retirement Review - When the administrator review is completed, the server should be handed off to the Production Supervisor for the pre-retirement review.  When this has been completed and reviewed, the server may be shutdown.
8. Server shutdown - The server OS is shutdown on the date of retirement.  The server is left in place and unchanged, should any issues come up.
9. Server Reuse / Removal - After the server has been deactivated for one week, it may be removed from the data center or re-installed for other purposes.

The Form:

Server Pre-Retirement Review

Decommissioning Requests / Administrator Review

All retiring servers must reviewed and decommissioned in accordance with the configurations made on the Server installation Checklist, Appendix B.  In addition to the decommissioning requests, the server administrator should confirm that the backup schedule is active and should confirm that the backups are functional.

Production Review

Once the Administrator review is complete, the server must be reviewed prior to retirement.  This review confirms the recoverability of the server and the removal from the production processes, checking on items including, but not limited to:

• Server retirement Request Completed
• Server removed from Monitoring
• Server removed from OUs (Retirement OU, if applicable)
• Server removed from System Management Software (Retirement category, if applicable)
• Server removed from Backup (retain retired servers on tapes for 1 year)
• Desktop Support Group updated with server retirement
• Server list updated with server retirement
• Server removed from logging page
• Data Center location information updated
• External firewall request provided to network group to removal all rules
• Retirement notice sent to Server Support team

This review is conducted by a Supervisor, once the Administrator has deemed their server retirement review completed and has handed the server off for the review.  The hand-off should include all server request documentation. When the supervisor has approved the server, the server request should be signed with the data, retirement approval status and reviewer name. 

Server Retirement Request Form

Requestor:  _______________________________    Date: _____________________________

Phone: __________________________________   E-mail: _____________________________

Server to be retired: ____________________________________________  

IP of Server to be retired: ____________________________________________  

Date and Time of requested Server retirement:  _____________________________

Check one:                                                                

_____Retire Server, End of Life

_____Retire Server, Reinstallation Request to follow

Backup Retention Specifics: ____________________________________________  

            Downtime / Change Request Attached (Required)

Please join us for the next article in the series when we will take a practical look at Incident Management.