Below is a checklist for SE/SE Customers:

Pre-decommission steps

• Verify with customer that the server is ready to be decommissioned and that appropriate CMDB relationships (database, service, application) have been handled. If applications, databases, or services have been migrated to other server[s], please update the relationships in the CMDB.
• Verify with customer that existing DNS records can be deleted. If you're unsure as to what DNS records exist, email hostmaster@doit.wisc.edu for a list of DNS records associated with an IP. Not all DNS records (e.g., MX records) are documented in the CMDB.
• Determine final disposition of server (e.g., SWAP, SEO Tech Lab, etc.)
• If a server is to be moved to the SEO Tech Lab, a new device installation request will need to be completed for the hardware to be installed in the SEO Tech Lab
• Determine how long Orca data should be retained
• Determine how long Bucky Backup data should be retained
• If the host was a member of a VIP, verify that any IP address[es] can be removed from an existing VIP. If this is the last balanced member of a VIP, determine if the VIP can be deleted. NOTE: VIP modifications will not be performed until after the server is shutdown. If L4 modifications need to be made prior to server shutdown, request them in a separate change record.
• If the host was a TWS workstation, determine if any existing jobs need to be moved to another server
• Review server relations in CMDB. Make note of any non-standard relations (e.g., external modems, RJ11 or ISDN connections) and determine what should happen to them

Decommission Request Process

Send your request for server decommissions to dcteam@doit.wisc.edu with configurationmanagement@doit.wisc.edu cc'd

• Please send as much of the following information to the Data Center Services Team as you can provide for your initial engagement.
• Disk Disposition: All local drives will be securely wiped by DC (or SE in the case of AIX and Mac OS X) unless directed otherwise by a SEO manager
• DNS Disposition: Indicate which DNS entries can be deleted. Use the CMDB and hostmaster to determine what DNS entries are associated with a host. It is acceptable to request that all DNS records associated with a specific IP address be deleted. If DNS entries need to be transferred to another host, request this work in a separate change record
• IP Disposition: Indicate which IPs can be reclaimed. Ensure the completeness of this list by verifying against system configuration and the CMDB. Please note that IPs might be associated with the host that are not currently active on the host. If IP addresses need be transferred to another host, request this work in a separate change record
• Monitoring: Unless stated otherwise, Orca data will be deleted after 6 months and OVO nodes will be deleted. Nagios nodes should be deleted by sysadmins
• Non-standard parts: Indicate what should be done with any non-standard hardware or connections
• Parts to Harvest: Note any physical components that should be removed from a server
• New location: Indicate final destination for any physical hardware (e.g., SEO Tech Lab or SWAP). Unless requested otherwise, 8th generation and newer Dell hardware will be reviewed for possible use in the SEO Tech Lab.
• Firewall: If the host is behind the data center firewall, please indicate this in the detailed description field to have the firewall rules removed
• Layer 4: If the host was a member of a VIP, please indicate this in the detailed description field case and ask that it be removed from the L4 config per KB 31870
• . NOTE: VIP modifications will not be performed until after the server is shutdown. If L4 modifications need to be made prior to server shutdown, request them in a separate change record.
• TWS: If the host was using TWS, mention this, and the DC Team will notify the Job Scheduling Team

Additional steps

• (Windows) Put the server in maintenance mode in OpenView Operations
• Delete the node from Nagios
• If the host was using enterprise storage, wipe the enterprise storage volumes, as appropriate
• If the server is running AIX, securely wipe all local drives
• Shutdown the server
• The DoIT Enterprise Storage Team will be notified if the host was using enterprise storage to let them know that the server is being decommissioned
• The Job Scheduling Services Team will be notified if the host was using TWS to let them know that the server is being decommissioned
• Request that Bucky Backup service be canceled or the server node's schedule[s] deleted using the Change/Cancel Bucky Backup Service Form
• If the server had a UW-Madison inventory tag on it, the Data Center Services Team will notify DoIT Purchasing that the server is being decommissioned
• Follow any additional SE team-specific decommission procedures:
• Linux
• Windows