Reimage Role Instance
Updated: June 29, 2015
The Reimage Role Instance asynchronous operation reinstalls the operating system on instances of web roles or worker roles.
The Reimage Role Instance request may be specified as follows. Replace <subscription-id> with the subscription ID, <cloudservice-name> with the name of the cloud service, <deployment-slot> with staging or production, or <deployment-name> with the name of the deployment. Replace <role-instance-name> with the name of the role instance.
Required. Specified that an instance of a role must be reimaged.
The following table describes the request headers.
Required. Set this header to application/xml.
Required. Specifies the version of the operation to use for this request. The value of this header must be set to 2010-10-28 or higher.
Required. Must be set to 0.
The response includes an HTTP status code and a set of response headers.
A successful operation returns status code 200 (OK).
The response for this operation includes the following headers. The response may also include additional standard HTTP headers.
A value that uniquely identifies a request made against the management service. For an asynchronous operation, you can call Get Operation Status with the value of the header to determine whether the operation is complete, has failed, or is still in progress.
When the role instance is reimaged, the instance is taken offline and a fresh guest operating system image is applied. The role instance is then brought back online. An attempt is made to maintain data in any local storage resources when the role is reimaged; however, in case of a transient hardware failure, the local storage resource may be lost. If your application requires that this data be persisted, it is recommended that you write it to a durable data source, such as an Azure drive. Any data that is written to a local directory other than that defined by the local storage resource will be lost when the role is reimaged.