12.15. Deployment Requests

12.15.1. Introduction

A Deployment Request is a set of instructions for Computers (with our Agent application). The Admin creates it, or anyone with the rights, to initiate a deployment cycle. A Deployment Request mainly contains the following types of information:

  • Request details: Defining the installation criteria.

  • Patch details: Selection of Patches that need deployment.

  • Computer details: Selection of Computers that perform deployment in their respective nodes.

Learn to create a Deployment Request

All Computers ping the Motadata server every hour to check for available Deployment Requests. On finding a Deployment Request, Computer/Computers can acquire the Patches from the File Server, and install them following a Deployment Policy. A Deployment Cycle refers to the end to end process involving getting and installing Patches.

Methods of Deployment

There are three ways to create a Deployment Request in the tool:

  • Manually creating a Deployment Request and publishing it.

  • Automatic Patch Deployment creates a Deployment Request (either in Draft or Publish).

  • Initiating an Automatic Patch Test which in turn creates and publishes a Deployment Request.

12.15.2. Manually Creating a Request

  • Click on the Launcher icon and select Patch.

  • Select Deployment Request from the Patch menu.

figure 62

  • The Deployment Requests page opens. Here you can view all available requests in the tool. Click on Deploy Patches situated in the top right corner of the page.

  • The Create page opens. The page is divided into four sections; they are as follows:

    1. Request Details:

      figure 63

      1. Name: You can provide a name to the Patch instead of the default placeholder. It is advisable to keep the date part of the placeholder.

      2. Deployment Policy: Select a Deployment policy from the drop-down list. A Deployment Policy governs how the deployment of Patches is carried out. Learn about Deployment Policies.

      3. Install After: Provide a date and time after which the request tells the Computers to commence the installation process

      4. Expire After: This is the date and time after which the request ceases to be a valid request.

      5. You can select whether you want to create the deployment for installation or uninstallation. When you select uninstallation, only the installed Patches are shown.

    2. Select Patch: Here you add the Patch/Patches that you want to deploy.

      figure 64

      1. Section-A (pf-64) is the area where you view the selected Patches.

      2. Section-B has a search bar for searching all available Patches for the selected platform. The search bar supports the Advanced Search feature. Learn how to use Advanced Search.

      3. Section-C is where you view the available Patches in the tool. Clicking a checkbox selects a Patch and transfers it to section-A.

      Select the Patches that you want to deploy.

    3. Select Target:

      figure 65

      Here you set your target computers. Patch will be deployed in the target computers. Here you can set the following things:

      1. Set a Remote Office. This will allow auto selection of multiple computers from a Remote Office’s network may or may not be based on include and exclude conditions.

        You can use a manage-computer-group to filter a Remote office. Computers (of the Remote Office) in the Group will be either included or excluded.

        figure 65.1

      2. Set individual computers.

      3. Set a different Scope (Target) if there are multiple Remote Offices.

    4. Retry Configuration

      figure 36

      The retry configuration limits the number of times an Agent tries deployment when faced with failure.

      1. You can define the maximum number of times to try deployment during system start-up.

      2. You can define the maximum number of times to try deployment once at each refresh cycle (by default refresh cycle is set to 1 hour).

      During each retry cycle, the deployment status swings from In-Progress to Failed and vice-versa for a single patch till success is reached in deployment.

Fill in all the necessary details. Now you have two options; you can publish the request or save it as a draft.

If you save the request as a draft, then the request appears as drafted in the Deployment Requests page. You can view all drafted requests using the Quick Filter Drafted.

figure 66

If you want to publish the request, then click on Publish. This might or might not activate the request immediately, depending on Custom Rules. If Patch Custom Rules demand Approval, then you have to seek Approval before you can publish the Request.

You can publish a drafted request from its Update page (clicking on a request opens its Update page).

12.15.3. Other Ways to Add a Manual Request

12.15.3.1. Deployment Request from the Patch List View:

Motadata allows you to select the Patches from the List View directly and deploy them.

  • Go to the Patch List View.

  • Select a Patch or Patches from the list area. A Deploy button appears above the list area.

figure 67

  • Click on Deploy, and the Create page opens. The selected Patch/Patches are preselected. Complete the request and deploy. Learn more about creating a Deployment Request.

12.15.3.2. Deployment Request from Patch Details View:

  • Go to the Details View of the Patch that you want to deploy.

  • Click on the Deploy button situated in the top right corner of the page.

figure 68

  • The Create page opens with the Patch preselected. Complete the Deployment Request. Learn more about Deployment Request.

12.15.3.3. Adding a Deployment Request from a Computer’s Details View:

  • Go to the Computer List View.

  • Click on a Computer. This takes you to the Details View of the Computer.

  • Click on Deploy Patches from the Action Menu.

figure 69

  • The Create page of Deployment Request opens. Create your request and publish it, or you can save it as a draft. Learn more about creating Deployment Requests.

12.15.4. Approval

In case there is a custom rule defined (Refer admin manual for Patch Custom Rules), then you have to make every drafted request go through an Approval process before publishing it. In an Approval process, you seek approval from a set of approver/approvers.

12.15.4.1. Asking for an Approval:

  • Go to the Deployment Request page.

  • Click on the Quick Filter Drafted to sort all drafted requests.

figure 70

  • Requests that haven’t gone through the Approval process have the Ask for Approval button adjacent to them.

figure 71

  • When Allow Manual Approval feature is turned on, you will be shown a dialog box that you can use to create a manual

Approval. If you skip this dialog box, then the Approval goes to the Workflow.

12.15.4.2. Different States in an Approval

  • Pending:

  • Rejected:

  • Pre-Approved:

  • Approved:

12.15.4.3. Approval Process:

In case of automatic approval, first, the system checks all available Approval Workflows when an Approval is asked. If there are no workflows or the workflow conditions are not meet, then the drafted request/requests are Pre-Approved, and you can proceed with publishing. If there is a workflow/are workflows, and their conditions are met, then approver/approvers are auto-assigned for each request.

When there are multiple requests, it may happen that some may trigger the Approval conditions and are put in Approval, and some may not trigger the conditions and are Pre-Approved.

figure 72

When you Ask for an Approval for a request, an Approval button appears adjacent to the request. The button gives you access to the Approval details dialog box where you can view all the approvers and their comments and even re-ask for an Approval (this again checks for all available workflows).

figure 73

For requests that have Approvers, the Approval Status changes to Pending, and it stays there as long as the approver/approvers don’t express a decision.

An approver can see his Approvals in the My Approvals section of his account.

figure 74

Clicking on My Approvals (pf-74) opens the My Approval page where he can view his Approvals.

figure 75

Clicking on an Approval in My Approval opens a new page. There he can perform the following actions:

figure 76

  • View request details, target Patches, and Computers.

  • Start a comment thread.

  • Approve or Reject the Approval.

The outcome of an Approval process is decided in two ways:

  • Unanimous: All of the Approvers have to approve else the Approval is rejected.

  • Majority: If the majority of Approvers agree then Approval is successful.

    In case there are multiple Approvals, the decision to go with unanimous or majority can be set from Admin (A Navigation Tab) >> Approval Workflow (Automation) >> Approval Settings, but the rights to do it lies with the Super Admin.

On success, the Approval moves to the Approved stage where the author can publish the draft. On failure, the Approval moves to the Reject stage where the author has to reinitiate the Approval process. The author reinitiates an Approval process using the Re-Approve option. A Re-Approve puts a request back to the pending stage.

figure 77

Any Technician with the Can Ignore Approval right can ignore approvers and push the Approval towards the Approved stage; where he can publish the draft. The ignored approvers can see their Approval status as Ignored in Approval details dialog box of the Article.

figure 78

12.15.5. Searching Deployment Requests

There are two broad ways to search Deployment Requests in the tool:

  • Using Search Bar

  • Using Filters

figure 79

12.15.5.2. Filters

You can search for requests in the Deployment Request page using Quick Filters. There three types of filters available:

  • Filters based on time of deployment.

  • Filters based on publishing status.

  • Filters based on origin.

figure 82

Section-A (pf-82) is a quick filter to toggle across the following views:

  • Current: Shows all the published and drafted requests that can start the deployment process immediately.

  • Future: Shows all the published requests that can start the deployment after a future date and time.

  • Past: Shows all the requests that have expired.

  • Drafted: Shows all drafted requests that are yet to be published.

  • Archived: Shows requests that have been deleted, includes drafted requests.

Section-B (pf-82) allows you to filter request based on origin and Approval status. There are three possible origins to a Deployment Request, and the Approval status shows both Approved and Pre-Approved requests.

12.15.6. Managing Deployment Requests

12.15.6.1. Deployment Status

In the Deployment Request page, every published request has a Status button.

figure 83

Using the Status button, you can check the download status of all associated Patches of a request, and associated Computers and their Deployment Status.

Clicking on a Status button opens a new page with the following tabs:

  • Patch Download Status: Here you can view all involved Patches and their download statuses. A Patch transitions through various statuses during a download cycle. Some of the statuses reflect a stage, and some are conclusions. Altogether there are six statuses:

    figure 84

    1. Pending: The Patch has been put in a queue by the Main Server for download. At this stage, you can cancel the process.

    figure 85

    1. Downloading: The Main Server is downloading the Patch. At this stage, you can cancel the process.

    2. Downloaded: The Main Server has finished downloading the Patch.

    3. Transferring: The Main Server is transferring the Patch to the File Server.

    4. Available: The Patch is available on the File Server for deployment.

    5. Cancelled: A user cancelled the downloading process, or there was an error in downloading the Patch. This error also comes when the File Server is not setup. You can restart the download process using the Retry button.

  • Computers: Here you can view all the associated Computers. Each computer has a Deploy Status button which opens a dialog box where you can view the installation statuses of each Patch. Computer transitions through various statuses when installing a Patch. Some of the statuses reflect a stage, and some are conclusions. Altogether there are six statuses:

    figure 86
    figure 87

    1. Yet to Receive: The Computer is yet to receive instructions from the request to install the Patch.

    2. In Progress: The Computer is in the process of installing the Patch after receiving the instructions.

    3. Success: The Computer has successfully installed the Patch.

    4. Failed: The Computer has failed to install the Patch.

    5. Cancelled: The request was deleted before the Computer could receive the instructions for installation.

    6. Not Applicable: The Patch is not meant for the Computer.

    7. FS Not Prepared: The main server has lost connection with the file server.

    8. DS Not Prepared: If there are Computers in a Remote Office, Patches are locally stored in Distribution Servers. This status shows that the concerned Patch is not available in the distribution server.

12.15.6.2. Unsupported Computers in a Deployment

During deployment it may happen that certain target Computers don’t support all the Patches; in that case, the Not Applicable status is helpful.

Go to the Status of a request. Click on the Deployment status of a Computer; there the Patches that don’t support the Computer have the Not Applicable status.

figure 88

12.15.6.3. Edit/Archive a Deployment Request:

You can update Deployment Requests that are in draft mode (both created manually and by an automatic process). Once published, a request cannot be edited.

  • Go to the Deployment Request Page.

  • The Status button adjacent to a request shows that the request is a published request.

  • You can open a request in edit mode by clicking on it or by clicking the Edit icon.

figure 89

Archiving

The tool allows you to delete published and drafted Deployment Requests. You can delete multiple requests at a time.

  • Go to the Deployment Request page from the Patch Menu.

  • Select one and more requests. The Archive button appears.

figure 90

  • Click on the Archive button. On confirmation, the request/requests are deleted.

Deleting an Active Deployment Request:

Deleting a published request has the following effects:

  • Installation of Patches is cancelled in Computers that are yet to receive instructions.

  • Downloading and transfer of Patches to the File Server continues even when the request is archived.

12.15.6.4. View Archived Deployment Requests

You can view an archived request along with its status. An archived request may have partially finished operations that might need scrutiny. To view an archived request:

figure 91

  • Now you can view all archived requests. Use the Status button to view deployment status.

figure 92