Decommissioning a server


In the provisioning environment, to remove one or more servers from TrueSight Server Automation, you can decommission the servers.


BMC recommends that you decommission any servers in your server environment that you do not plan to manage with TrueSight Server Automation. This recommendation also applies if you are using other products in addition TrueSight Server Automation to manage your server environment; if for some reason a server managed by TrueSight Server Automation is removed from the environment using another tool, you must also decommission the server using TrueSight Server Automation.

Note

Decommissioning a server using TrueSight Server Automation is the only way to remove the server from the license count.For more information, see Licensing considerations in server management.

In general, decommissioning a server removes that server from view in the TrueSight Server Automation Console and makes it unavailable for any operation. However, in most cases the server's data and references (jobs, job results, job runs, and provision history) are maintained in the database. There are exceptions, however, based on if the job used servers or components as targets.  

Click here for more information.

Decommissioning a server has the following effects:

  • The server no longer appears when you live browse in the TrueSight Server Automation Console.
  • The server is no longer available for any operation. For example, the server no longer appears in server groups. In addition, if you show the targets of a job, the decommissioned server is dimmed and marked as decommissioned.
  • Components associated with the server are marked for deletion in the database. When you run the database cleanup utility, these components are deleted from the database.

However, a decommissioned server is not marked for deletion in the TrueSight Server Automation database.

For detailed information about decommissioning a server, see About-decommissioning-servers.

Decommissioning a server lets you reprovision or repurpose the server. For example, you may want to install a different operating system and different applications on the same physical hardware. To do this, you need to decommission the server, repurpose it, and then add the newly configured server back into the system. Repurposing a server in this way lets you keep the same host name for the machine.

Note

When you repurpose a server and add it back into the system, you must redefine jobs for the newly configured server. Any jobs you defined for the server before you decommissioned it do not run on the server when you add the server back into the system, even if you keep the same host name for the machine. For information about jobs, see Basic-concepts-for-jobs.

To decommission a server

  1. Do one of the following:
    • Use the Servers folder to navigate to a server you want to decommission.
    • Use the Servers folder to select the group or smart group containing the servers you want to decommission. Right-click and select Group Explorer. A Group Explorer view opens. Select the servers you want to decommission.
  2. Right-click and select Administration Task > Decommission Server.

    The Decommission Servers dialog box appears.
  3. Click OK to confirm that you want to decommission the servers listed in this dialog.

A background process decommissions the server or servers. Depending on how you have specified behavior for background processes, either a dialog box appears or the Show background operations icon g_v95_showBackgroundOperationsIcon.gifappears in the lower right corner of the console. Both indicate an operation is running in the background. For information about the dialog box and background operations, see Running-background-operations.


To skip dependant access checks for decommissioning a server

A server object can have dependent objects (for example, components). When a server is decommissioned, the dependent objects must be deleted. If the role that is decommissioning the server does not have the required permission to delete the dependent objects, the decommissioning fails because of RBAC checks.

The SkipDependantAccessChecksOnServerDecomm setting allows you to decommission a server, even though you do not have the required permissions to delete the dependent objects. However, your role must have the server.read and server.decommission authorization on the specific server object(s).

The default value of SkipDependantAccessChecksOnServerDecomm is false.

To modify the setting, run the following command in the blasadmin console and restart the Application Server:

set cleanup SkipDependantAccessChecksOnServerDecomm true

For information about starting the blasadmin console, see Starting-the-Application-Server-Administration-console.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*