IBM Systems Middleware Professional Certification Program

Study Guide Series

Exam C9530 - 680 - IBM Control Desk v7.6 Fundamentals

Purpose of Exam Objectives ...................................................................................... 3

High-level Exam Objectives ........................................................................................ 4

Detailed Exam Objectives ........................................................................................... 5

Section 1 - IBM Control Desk Concepts ................................................................................. 5

Section 2 - General Installation and Deployment IBM Control Desk ........................... 12

Section 3 - Configure IBM Control Desk .............................................................................. 17

Section 4 - Usage of IBM Control Desk ................................................................................ 27

Next Steps ...................................................................................................................... 44

Purpose of Exam Objectives

When an exam is being developed, the Subject Matter Experts work together to define the role the certified individual will fill. They define all of the tasks and knowledge that an individual would need to have in order to successfully implement the product. This creates the foundation for the objectives and measurement criteria, which are the basis for the certification exam. The Middleware Certification item writers use these objectives to develop the questions that they write and which will appear on the exam. It is recommended that you review these objectives. Do you know how to complete the task in the objective? Do you know why that task needs to be done? Do you know what will happen if you do it incorrectly? If you are not familiar with a task, then go through the objective and perform that task in your own environment. Read more information on the task. If there is an objective on a task there is about a 95% chance that you WILL see a question about it on the actual exam. After you have reviewed the objectives and completed your own research, then take the assessment exam. While the assessment exam will not tell you which question you answered incorrectly, it will tell you how you did by section. This will give you a good indication as to whether you are ready to take the actual exam or if you need to further review the materials. Note: This is the high-level list of objectives. As you review these objectives, click for a more detailed level of how to perform the task.

High-level Exam Objectives

Section 1 - IBM Control Desk Concepts

1.1 Explain Service Management Concepts and their interdependencies.

1.2 Explain the processes and capabilities of Service Desk and Self Service.

1.3 Explain the processes and capabilities of Service Catalog and Self Service.

1.4 Explain the capabilities of Configuration Management, Change Management and Release Management.

1.5 Explain the capabilities of IT Asset Management (hardware and software).

Section 2 - General Installation and Deployment IBM Control Desk

2.1 Describe the various offering types (IBM Control Desk, IBM Control Desk Internal Service Provider, IBM Control Desk External Service Provider).

2.2 Describe the various deployment options (On Cloud/SaaS, On Premises).

2.3 Understand the installation process and steps.

2.4 Explain the general architecture of IBM Control Desk on the different deployment options.

2.5 Explain the methods and tools that support external integration ( ITIC, Integration Framework, IBM Security Directory Integrator (previously TDI), etc).

Section 3 - Configure IBM Control Desk

3.1 Explain the security options including people and users for IBM Control Desk.

3.2 Perform the initial configuration which includes IT foundation data (organization, sites, etc.)

3.3 Understand report administration, security and reporting capabilities.

3.4 Explain the IBM Control Desk options for logging (serviceability logging).

3.5 Summarize the system configuration options (system properties, cron tasks, etc).

3.6 Explain how workflows and escalations can be configured.

3.7 Perform UI changes and database configuration modifications.

Section 4 - Usage of IBM Control Desk

4.1 Demonstrate knowledge of basic navigation and UI usage.

4.2 Perform Service Desk Management.

4.3 Demonstrate knowledge of managing IT hardware and software assets.

4.4 Demonstrate knowledge of Configuration Management, Change Management and Release Management.

4.5 Perform troubleshooting and problem determination on IBM Control Desk.

4.6 Create ad-hoc reports and run system reports.

Detailed Exam Objectives

Section 1 - IBM Control Desk Concepts

1.1. Explain Service Management concepts and their interdependencies. SUBTASK(S): 1.1.1. Service management concepts are often described & defined through the framework of

ITIL ( IT Infrastructure Library), IBM Control Desk is aligned and certified with the ITIL framework.

1.1.2. Service management begins with understanding the customer and their requirements to enable the changes needed in IT processes, people and tools, allowing IBM Control Desk to be configured to support the organizations business processes and optimize output

1.1.3. Service management is defined as a set of specialized organizational capabilities for providing value to customers in the form of IT services, which can be managed through a services lifecycle.

1.1.4. Service management envelopes many business processes. ITIL framework sets them in the structure of strategy, design, transition, operation ,and continual improvement. IBM Control Desk aligns with these areas of focus for Service Management.

1.1.5. IBM Control Desk focuses on the processes of Self Service, through issue reporting, a catalog of services, these service requests are flowed through automation or the service desk along with incidents allowing for resolution to challenges. The root cause of these can be reviewed through problem management.

1.1.6. Service Management includes the processes and functions of managing IT Assets. IBM Control Desk provides capabilities for the management of IT hardware and software through a full lifecycle including request to retirement and as well is a supporting structure to the service desk, incident, as well as all change and work delivery.

1.1.7. Service management drives a business to focus on their overall infratructure, this includes configuration items, changes, release and all supporting services. IBM Control Desk enables these management areas to ensure IT operations are optimized and data is accurate for effective processes.

1.1.8. All processes within IBM Control Desk interlock and support each other by design and allow interaction from the beginning and end of each process individually. This is based on the overall structure of Service Management and is concepts for delivering services (internal) to the business.

1.1.9. Services: a means of delivering value to customers (internal, or external) by facilitating outcomes, customers want to achieve without the ownership of the service assets and risks. IBM Control Desk Service provider enable the business to provide extensive services and ensure effectiveness to the business overall strategy.

1.2. Explain the processes and capabilities of Service Desk and Self Service. SUBTASK(S): 1.2.1. Describe different types of tickets and their purpose & use: 1.2.2. Service Request: A service request is created to capture and resolve requests from

customers or requestors. The request can be to resolve an issue, obtain a new service, obtain information or change a current service. Either a service desk agent or a customer can create a service request.

1.2.2.1. Incident : an incident is created to capture any event that is not part of the standard operation of a service and that causes or might cause an interruption to or reduction in the quality of service. Sources of incidents include Users, Operations and network/system management tools. The goal of incident management is to restore normal service operation as quickly as possible.

1.2.2.2. Problem: a problem record is created to capture an unknown, underlying cause (root-cause) of one or more incidents. The goal of problem management is to minimize the adverse effect on the business of incidents and problems by identifying errors in infrastructure, and to proactively prevent the reccurrence of incidents, problems and known errors.

1.2.3. Explain Service Request Fulfillment process: 1.2.3.1. Purpose of Service Request Fulfillment process: to provide information to

users and customers about services, to provide a channel and mechanism for users to request and receive service, etc.

1.2.3.2. Main process activities: Menu Selection, Financial Approval, Fulfillment, Closure.

1.2.3.3. Inputs to Service Request Fulfillment process, Event Management, Incident Management.

1.2.3.4. Outputs of service request management process include request for change for request fulfillment, incident ticket, communication to customer, requester satisfaction survey, resource and work planning

1.2.4. Explain Incident Management process: 1.2.4.1. Purpose of Incident Management process: to restore normal service operation

as quickly as possible and minimize the adverse impact on business operations.

1.2.4.2. main process activities: Identification, Logging, Categorization, Prioritization, Initial diagnosis, Escalation, Investigation, Resolution, Closure.

1.2.4.3. Primary inputs to Incident Management process are Event Management, Requester, Technical staff.

1.2.4.4. Primary outputs of Incident Management process are request for change for Incident resolution, Problem Management, resolved and closed incident, requester satisfaction survey, resource and work planning

1.2.5. Explain Problem Management process: 1.2.5.1. Purpose of Problem Management process: to prevent problems and resulting

incidents from happening, to eliminate recurring incidents and to minimize the impact of incidents that cannot be prevented.

1.2.5.2. Main process activities: Problem detection, Logging, Categorization, Prioritization, Investigation and Diagnosis, Workarounds, Raising a known error record, Monitor – Track - Report Problems, Resolution, Closure.

1.2.5.3. Primary inputs to Problem Management process are recurring incidents, knowledge management, proactive processes such as Capacity or Availability Management.

1.2.5.4. Primary outputs of Problem Management process are Known Errors, Request for Changes, Service Requests, Work arounds, event management, Knowledge Management.

1.2.6. List common ticket tasks : many aspects of working with a ticket are similar regardless of the type of ticket. 1.2.6.1. Global Search allows to search across different ticket applications at the same

time.

1.2.6.2. Priority Matrix allows to manage priority of tickets based on Impacts and Urgency.

1.2.6.3. Solutions allow to search, apply, or create a predefined response to a common ticket.

1.2.6.4. Service Level Agreements can be applied to tickets to ensure agreed level of IT service is provided.

1.2.7. Explain self-service process and capabilities. 1.2.7.1. Purpose of Self-Service: Self-service helps to offset traditional methods of

securing services or information such as contacting help desks by telephone and or email. Self-service allows end-users to research and secure answers to their inquiries for information on how-to, how-much, etc. It also enables end-users to request products and services though self-creation of service requests by means of a published service catalog, an application store, or a decision tree driven by structured or unstructured queries they invoke against a knowledgebase. Multiple service requests may be collectively placed in a shopping cart, for submission en mass. Self-service can also provide new methods of contacting help desk or service personnel, though different mediums such as electronic chat. Self-service users can also obtain current and relevant information and bulletins from a single user-friendly portal, without contacting the service desk or searching for information by other means. Self-service also enables end-users to obtain status on in-process service requests and assets which are assigned to them or for which they are custodians & owners of. Self-service may be backended by workflows and automation to speed or enhance the provisioning of products and services.

1.2.7.2. Main process activities: Information and knowledge inquiries and structured queries; access to structured service catalogs and stores; self-generation of electronic service requests and incident tickets as well as current status and detailed information related to these requests; placement of requests for multiple product and services into a shopping cart for concurrent submission; access to detailed information on assets that are assigned to them; access to relevant information via an electronic bulletin board; and access to help desk and service delivery personnel through electronic chat.

1.2.7.3. Primary inputs to Self-Service: Knowledge management; catalog offerings; service request and incident ticket status and details; electronic notifications and bulletins; asset information and details; electronic chat integration to service delivery personnel.

1.2.7.4. Primary outputs of Self-Service: service requests and incident tickets; feedback on quality and helpfulness of cataloged service and or knowledge query output; electronic communication to service delivery personnel; activity and metric reporting on self-service functions.

1.3. Explain the processes and capabilities of Service Catalog and Self Service. SUBTASK(S): 1.3.1. Summarize the key characteristics of the Service Catalog

1.3.1.1. It enables requestors to look for published IT and other service offerings in an easily accessible and searchable manner.

1.3.1.2. Offerings can be restricted to different sets of users 1.3.1.3. It works like many of the online shopping sites where a product can be

selected, added to a shopping cart, and purchased. 1.3.1.4. Internally, the catalog contains structured processes that manage the manner

in which each service is delivered. 1.3.2. Describe the major elements of the Service Catalog

1.3.2.1. Designing and Publishing Services – Offerings and catalogs are created and published. 1.3.2.1.1. Offering: Refers to an item which can be ordered by a user.

Offerings can initiate a workflow, launch another application, or display information to a user.

1.3.2.1.2. Catalog: A container for one or more offerings that can be requested by a user. Catalogs are created to help organize offerings.

1.3.2.2. Shopping and Requesting Services – Focuses on the shopping experience. 1.3.2.2.1. Shopping Cart: Container used to hold offerings the user intends to

order 1.3.2.2.2. Users can search using the Self Service Center, the self service

user portal or the Offering Catalog application 1.3.2.2.3. Catalog Request: One or more offerings that have been ordered by

a service requester. 1.3.2.2.4. Service Request: Generated from each Catalog Request.

1.3.2.3. Fulfillment of Service Requests – The selected offerings are approved and fulfilled. 1.3.2.3.1. Approval: Service Requests may need to be approved before the

request is fulfilled. Separate approval workflows for Line Management and Fulfillment Management can be configured.

1.3.2.3.2. Work Order / Process Objects: The Service Request can generate work orders with pre-defined job plans for service requests that can be fulfilled.

1.3.2.3.3. Service Request automation can also be used to generate objects like Incidents, Problems, Changes and additional Service Requests.

1.3.3. Describe the major configuration elements that are used in a Service Catalog offering order panel. 1.3.3.1. Description: Both short and long descriptions are displayed within the Offering

order panel. 1.3.3.2. Icon: A description icon can be associated with an Offering to make it easier to

locate during browsing. 1.3.3.3. Classification: Controls where the Offering is placed within the Service Catalog

offering hierarchy. 1.3.3.4. Automation Scripts: Scripts can be configured to operate at different points

during the user’s shopping experience. They can be used to do things such as preset attribute values, validate attribute values and cause side effects in other attributes.

1.3.3.5. Presentation Type: Offerings can utilize a simple “default” presentation type or the developer can define a custom XML presentation UI.

1.3.3.6. Specifications: Specification Attributes define parameters that will be associated with the user’s request. Domains and Validation Scripts can be used to limit or sanity check attribute values. “Default” presentations provide a variety of data entry behavior options for attributes.

1.4. Explain the capabilities of Configuration Management, Change Management and

Release Management. SUBTASK(S): 1.4.1. The purpose of the Change Management process is to achieve the successful

introduction of changes to an IT system or environment. Success is measured as a balance of the timeliness and completeness of change implementation, the cost of implementation, and the minimization of disruption caused in the target system or environment. 1.4.1.1. Main process activities are create and record Requests for Change, Review,

Assessment and Evaluation, Authorization, Coordination of the implementation, Review, Closure.

1.4.1.2. Primary inputs to Change Management process are Service Disruption, Known error, Service Strategy, Change proposal, Service Request and Configuration Management.

1.4.1.3. Primary outputs of Change management are Rejected RFCs, Approved Changes, Change to the services.

1.4.2. Explain Release Management process. 1.4.2.1. Release Management is the controlled deployment of approved changes within

the IT infrastructure. Release management involves a collection of hardware, software, documentation, processes or other components required to implement one or more approved Changes to IT Services. The contents of each Release are managed, Tested, and Deployed as a single entity.

1.4.2.2. Main process activities are Planning and Strategy, Design and Build, Test & Verify, Roll back (also known as backout) mechanisms and procedures, Monitor and Report, Review and Close.

1.4.2.3. Primary inputs to Release Management processes are Authorized changes, Solution Acceptance, Asset Management, Operation plans, and standards.

1.4.2.4. Primary outputs of Release management are Asset Management, Change Management, Deployment Management, New or Modified Services, Incident Management, and Problem Management.

1.4.2.5. List the types of work orders that are managed by Change and Release processes. 1.4.2.5.1. Change records allow to plan, review, and report actuals for

implementing changes or deploying new standard configuration for existing assets.

1.4.2.5.2. Release records allow to plan, review, and prepare for batched changes to assets.

1.4.2.6. List common work order management tasks. 1.4.2.6.1. Work Order management plans allow creation of tasks for the work

order, and specification of estimates for labor, craft, materials, services, and tools.

1.4.2.6.2. Scheduler allows management and scheduling of tasks. 1.4.2.6.3. Assignment manager allows dispatch of labor.

1.4.2.7. Explain Configuration Management process. 1.4.2.7.1. Configuration Management identifies, controls, and maintains all

elements in the IT infrastructure called Configuration Items. The purpose of the Configuration Management process is to maintain the integrity of the configuration item (CI) employed in, or related to, IT systems and infrastructure, and to provide accurate information

about CIs and their relationships. 1.4.2.7.2. Main process activities are Management and Planning,

Configuration Identification, Configuration Control, Status Accounting and Reporting, Verification and Auditing.

1.4.2.7.3. Primary inputs to Configuration management process, are Change requests, Asset Management, Solution Analysis and Design, Solution Development and Integration, CI/Discovery Data and Information, Acquisitions and Service Requests.

1.4.2.7.4. Primary outputs of Configuration management are CIs and information, CI Attributes and Relationships, input to key Service Management processes.

1.4.2.8. Explain the two Configuration Management processes predefined by IBM Control Desk. 1.4.2.8.1. Update configuration items (CIs) that consist in updating one or

more configuration items. 1.4.2.8.2. Audit CIs that consist in comparing the “as built” and “as planned”

versions and attributes of CIs, investigating discrepancies, and taking action on the results, in order to identify unauthorized changes or failures to carry out approved changed requests.

1.4.2.9. Describe CIs that are managed by Configuration management processes. 1.4.2.9.1. A CI is any service component, infrastructure element, or other item

that needs to be managed in order to ensure the successful delivery of services.

1.4.2.9.2. Each CI has multiple characteristics: A classification, Attributes, A status value, Relationships, an owner.

1.5. Explain the capabilities of IT Asset Management (hardware and software). SUBTASK(S): 1.5.1. Full IT asset lifecycle management:

1.5.1.1. IBM Control Desk enables a business to manage hardware and software IT assets by using the IT asset management capabilities including the lifecycle from planning to retirement.

1.5.1.2. Control Desk IT Asset mgmt Lifecycle phases include: Plan, Acquire, Deploy, Maintain and Retire. The solutions supports the functions, tasks and capabilities in all phases. 1.5.1.2.1. Plan: In the Plan phase, a company formulates a budget and an

associated schedule for hardware and software acquisitions. The technology refresh cycle indicates when existing assets need to be replaced based on company policy. Stockrooms are used to keep spares and check inventory before a purchase is made.

1.5.1.2.2. Acquire: In the Acquire phase, the asset is purchased and created in the application. An established purchase order approval process expedites and controls purchasing. Assets can be created from a PO, receipt of an asset into inventory, or directly from a vendor. Deploy: In the Deployment phase, assets are assigned to an employee, project, or business unit. Employee information, including location, is received from Human Resources (HR). The status of the asset is tracked as it moves throughout the IT asset management

lifecycle. Communication with the user provides a smoother deployment. Integration with the Service Desk can generate service tickets for the technician.

1.5.1.2.3. Maintain: In the Maintain phase, asset reconciliation occurs between what is discovered and what has been purchased. Installations, moves, additions, and changes (IMAC) must be recorded. Integration with Change Manager provides more robust change management processes, such as requests for change (RFC) to be implemented. During the Maintain phase, asset costs are managed by software license compliance, monitoring stock rooms, and viewing software use.

1.5.1.2.4. Retire: In the Retire phase, an asset has reached its end of life. The asset can be disposed of, auctioned, donated, and sold to an employee, returned to a leasing company, or purchased.

1.5.1.3. Reporting on or about IT Assets is critical in today’s business structure in an effort to support regulations such as SOX or software compliance. IBM Control Desk enables out of the box reports for the life cycles as well as the ability for adhoc, queries, downloads and result sets.

1.5.2. Financial Management of IT Assets (hardware & Software): 1.5.2.1. A purchase request is a request issued internally to a purchasing department

to order materials or services for IT services which are necessary for IT purchases. Control Desk enables the recording and tracking of these costs in connection to the IT assets.

1.5.2.2. Request for quotations - Used to request price quotations from vendors for IT asset items or Asset services. Control Desk functions allow for creating a purchase order when awarding the quotation to a vendor, the purchase order would track the costs of the purchase, with history of the quotations of the award.

1.5.2.3. Purchase orders are authorized orders of hardware or software from a purchasing agent or department to an internal supplier or external vendor. The finanical costs of the purchase would be recorded in reference to the asset for further review and understanding of the costs of the asset at the start of the acquisition.

1.5.2.4. Receiving – Use of the Receiving application to receive IT materials (software and hardware) and services from purchase orders. Control Desk enables the financial costs of the asset to be viewed from the asset record and can be accounted for throughout the lifecycle of the IT asset and its support.

1.5.2.5. Invoices - An invoice is a bill from a vendor for delivered products or services. Financial costs from vendors in the form of an invoice details against POs and receipts, for the IT assets to ensure accurate costs and payment for IT assets in the acquisition phase.

1.5.2.6. Work order or tickets – Assets are often referenced on Service requests incidents. Work orders and changes. The costs associated to the asset can be viewed based on these work records as the labor or support equates to costs towards the ownership of the assets.

1.5.3. Broad support for software license management in interlock with hardware assets. 1.5.3.1. Software License management enables the understanding and the ability to

Find the software that the business has deployed. 1.5.3.2. Control Desk helps the asset mgmt resources to verify if the license

agreements and software contracts are efficient and correctly aligned to the current need.

1.5.3.3. Software License controls in IBM Control Desk provides information on expiration of lease, support, and warranty agreements that support licenses and hardware IT assets. 1.5.3.3.1. Licenses application can be used to define the entitlements for

software within the enterprise. 1.5.3.3.2. Software License Audit Readiness -Identifies underutilized or over

utilized software to reduce costs from over purchasing and to reduce risk to under purchasing.

1.5.3.3.3. License Audit reports can be used to compare what you have purchased to what you have deployed.

1.5.3.4. IT asset (hardware or software) reconciliation control and processes 1.5.3.4.1. Control Desk enables a business to link and compare their assets

and configuration items based on authorized and what is actually found in the infrastructure.

1.5.3.4.2. In order to maintain data accuracy and infrastructure of the IT asset portfolio customers can enable reconciliation processes such as Link, synch, and compare rules to ensure the assets and configuration items are maintained correctly recorded and maintained.

1.5.3.4.3. When reconciliation is in work IBM Control Desk enables the processes and corrective updates to the assets to ensure data accuracy of the IT Assets to ensure support to all Service mgmt. processes.

1.5.3.4.4. Reconciliation capabilities can be used to reconcile authorized asset data with deployed asset data that is gathered by asset discovery tools.

Section 2 - General Installation and Deployment IBM Control Desk

2.1. Explain the various offering types (IBM Control Desk, IBM Control Desk Internal Service Provider, IBM Control Desk External Service Provider).

SUBTASK(S): 2.1.1. Describe the IBM Control Desk offering:

2.1.1.1. This edition provides a comprehensive range of product features. Users can use special tools to import and discover assets and configuration items (CIs) across the data center; manage licenses, including software contracts; manage assets, changes, releases, and configuration; operate a full-featured service catalog and service desk; and generate and manage incidents and problems. This edition includes several sophisticated workflows that enable you to direct IT processes in predictable, repeatable ways, along with integration and customization capabilities. In addition, it includes the CMDB for storing and managing data.

2.1.2. Describe the Service Provider offering: 2.1.2.1. The Service Provider Edition contains all of the features and functionality

provided in IBM Control Desk. In addition, this edition includes applications and capabilities that are specifically designed for service providers who are

managing the data centers of multiple customers, or those who want to provide additional levels of segmentation within the tool (customers; locations; service catalogs; ticketing; assets; etc.). IBM Control Desk’s Service Provider Edition comes in two (2) versions: Internal Service Provider; External Service Provider.

2.1.2.2. Internal Service Provider is used in scenarios where it is deployed within a single company or entity (large Global corporation; University with multiple campuses; local government; etc.), and there is a need to provide a level of segmentation around the customers, locations, service offerings, assets, ticketing, work orders, etc.

2.1.2.3. External Service Provider is used in scenarios where the prime service provider provides services to external customers – not those internal to its own organization (e.g., telecommunication providers; ISPs; retail and commercial businesses; etc.).

2.2. Explain the various deployment options (On-Cloud/SaaS, On-Premise). SUBTASK(S): 2.2.1. Define scenarios where IBM Control Desk would be deployed using the On-

Cloud/SaaS model. 2.2.1.1. On-Cloud/SaaS is a “Software as a Service” deployment option whereby the

solution is deployed in a Web-Based cloud infrastructure, and is hosted and administered by IBM in one or more of its global data centers. IBM provides all the necessary infrastructure to its standards (operating system; middleware; hardware; configurations; etc.), as well as provides the day-to-day administration and break/fix of the system and environment. The client service subscriber is responsible for the administration of the application. IBM also provides and is responsible for patching and deployment of periodic version releases.

2.2.1.2. External Service Provider Edition is not available in the IBM-hosted (SaaS) deployment option.

2.2.1.3. Internal Service Provider Edition is included in the standard IBM-hosted (SaaS) deployment option.

2.2.1.4. IBM Control Desk On-Cloud/SaaS is a subscription-based offering. 2.2.1.5. IBM Control Desk On-Cloud/SaaS has both Authorized (Named) and

Concurrent based user access subscriptions. 2.2.2. Define scenarios where IBM Control Desk would be installed using the Enterprise/On-

Premise model. 2.2.2.1. Enterprise/On-Premise is a deployment option whereby the client installs,

maintains, and supports the application on its own (or 3rd party) hosted infrastructure and data center(s). The client makes all the standards decisions (operating system; middleware; hardware; configurations; etc.), and is responsible for day-to-day administration and operation & break/fix of the application hosting environment. The client is responsible for the administration of the application. The client is responsible for patching and deployment & testing of periodic version releases.

2.2.2.2. Enterprise installation uses Launchpad on a client workstation. 2.2.2.3. Internal Service Provider Edition is available in this deployment scenario as

an option.

2.2.2.4. External Service Provider Edition is available in this deployment scenario as an option.

2.2.2.5. When installed as an enterprise/on-premise solution, the client can install any of the product editions, in any of the IBM recommeded architectures and configurations.

2.2.2.6. IBM Control Desk Enterprise/On-Premise is a perpetually licensed offering, which includes IBM’s Software Subscription & Support (S&S) in the first-year, and is renewable at a cost based upon configuration in years 2 – n.

2.2.2.7. IBM Control Desk Enterprise/On-Cloud has both Authorized (Named) and Concurrent based user access licenses. There is no charge for end-user access to IBM’s Control Desk’s Self-Service facility and portal, nor to any of the functionality provided therein.

2.2.3. Define scenarios where IBM Control Desk would be installed using the optional user interface – Service Portal. 2.2.3.1. IBM’s Control Desk Service Portal provides a new optional user interface that

can be used to manage service tickets and other self-service functions. 2.3. Understand the installation process and steps. SUBTASK(S): 2.3.1. Identify PreReqs to Installing IBM Control Desk - Customer requirements will influence

what the middleware needs to look like: Clustering, Single Sign On (SSO), LDAP integration, Reporting Server, SSL, External Integrations, High Availability, Disaster Recovery, etc. We need to understand the basic installation process and how other factors influence the middleware and ICD. It is important to understand that SSO or SSL will not require additional middleware resources. Knowing that Clustering affects more than memory, disk space, and number of computers, Clustering also may require us to have a network drive to support attachments or data loading across different machines. We should focus on the main install options and path but understand how optional integration points will potentially impact our infrastructure. 2.3.1.1. Identifying the hardware, software, and user access necessary to install ICD

and the middleware. 2.3.1.2. Downloading the middleware, ICD software, and the latest fixpacks (Extreme

leverage, Passport Advantage, Fix Central, identifying part numbers, etc) 2.3.2. Identify the software components used with IBM Control Desk installation - It is

important to understand high level what is the function of each middleware piece. Know that IHS is a WebServer and can be used to do load balancing, port forwarding, and serve attachments. 2.3.2.1. Identify what a J2EE server is– IBM Websphere, Oracle BEA Weblogic. 2.3.2.2. Identify what a Webserver is – IBM HTTP Server, Oracle BEA Weblogic, IIS,

F5 2.3.2.3. Identify what a LDAP Server is – IBM Directory Server, Microsoft Active

Directory 2.3.2.4. Identify what a Database is – IBM DB2, Oracle or SQL Server.

2.3.3. Understand the IBM Control Desk options being installed - Understanding high level the options you have to install with is paramount here. It is not important to memorize for DB2 did you run these 40 commands to set it up correctly. Those are listed in the install document and can be referenced at install time. 2.3.3.1. Review and Understand the ICD installation documentation. Need to

understand that various deployment options and how to use the installer. Example: ICD supports 3 different security types, what are the different clustering options, etc.

2.3.3.2. Install IBM Control Desk. The installer has completely changed with the 7.6. Understanding the new break down for each Installer and what functionality/choices are in each of them. 2.3.3.2.1. Run the middleware system requirement test. 2.3.3.2.2. Launchpad->Install Product->Install IBM Control Desk

Components(Laying down basic middleware with no configurations)

2.3.3.2.3. Launchpad->Configure Product->Launch the Tivoli Process Automation Suite Configuration Program (Installing ICD and configuring the middleware. Installer now supports clustering)

2.3.3.2.4. Identifying and Install Optional Tooling (ITIC, TDI, Cognos, Birt, Deployers Workbench, etc)

2.3.3.2.5. Optional Content vs Process Content Packs (knowing what comes in each, because they can't co-exist and we have to know which one we should use/pick).

2.4. Explain the general architecture of IBM Control Desk. SUBTASK(S): 2.4.1. IBM Control desk

2.4.1.1. Change Management and Configuration Management 2.4.1.2. Service Desk Management - Service Request Management, Self Service

Management, Service Catalogue 2.4.1.3. IT Hardware and Software Asset Management

2.4.2. Middleware - The ICD products can be deployed with new middleware or reusing existing middleware. T Understand types of middleware and the requirements for each. 2.4.2.1. Database server

2.4.2.1.1. IBM Control Desk requires its own separate database to run. What are the requirements needed to install into a database. (Db user, table space, index space, temp space, etc)

2.4.2.1.2. What are the 3 different types of DBs we support. 2.4.2.1.3. What other middleware components (besides ICD) may require a

separate database to run (WebSphere JMS, ITDS, etc) 2.4.2.2. J2EE server

2.4.2.2.1. Explain how ICD interacts with WebSphere - LDAP, JMS queues, etc

2.4.2.2.2. How to manage ICD from WebSphere 2.4.2.2.3. What J2EE Servers and versions do we support (Websphere and

WebLogic) 2.4.2.2.4. HTTP Server 2.4.2.2.5. Explain how the webserver does. (Load balancer, serve unsecured

attachments, port forwarding) 2.4.2.2.6. The types we install with and types we can integrate with - IIS, IHS,

F5 2.4.2.3. Administrative Workstation

2.4.2.3.1. Administrative workstation is required for the initial installation and configuration of IBM Control Desk.

2.4.2.3.2. Understand the new ConfigUI tool and its features ( located in the Administrative Workstation). This now supports multiple common operational duties: Update user/password credentials, rebuild and redeploy ear files, change ICD security type, etc.

2.4.3. High Availability, Disaster Recovery, Types of Environments 2.4.3.1. Application Server High Availability - Vertical and Horizontal Clustering 2.4.3.2. Database High Availability - Failover, replication, backups, etc 2.4.3.3. Disaster Recovery - Hot and Cold standbys, Geographical location, etc 2.4.3.4. Types of environments - Development, Quality Assurance, Production, User

Acceptance Testing, etc 2.4.4. Reporting Server - Discuss about the different optional for tooling that is supported in

the product. 2.4.4.1. BIRT - Control Desk has hundreds of built-in reports. How to generate, view,

schedule those reports. 2.4.4.2. BIRT Developer - Eclipsed based tool to change load, create, and change

reports. 2.4.4.3. Cognos - External Reporting Server that can be used to create additional

reports for ICD 2.4.4.4. Crystal ,etc. There are many other reporting solutions you could integrate

here. 2.4.5. Security (Authorization/Authentication) - Discuss about the different optional for tooling

that is supported in the product. 2.4.5.1. Applcation Server Security - WebSphere User Management, VIrtual member

management (VMM), Application - Security Role to user/Group Mapping, Single Sign On, SSL

2.4.5.2. LDAP Security - Single SIgn On, User and Group Management (ITDS) 2.4.5.3. Control Desk Security

2.4.5.3.1. Local Security - ICD manages all user and group security internally 2.4.5.3.2. LDAP Authentication only - ICD pulls user data and does

authentication with an LDAP server 2.4.5.3.3. LDAP User and Group Management - ICD pulls user and group

information from LDAP. LDAP handles all of the authentication and authorization.

2.4.6. External Integration with IBM Control Desk - What Integration points does ICD support to external Applications: ITIC, Web Services, Rest Api, Integration Framework, etc. Users need to be able to identify the common integrations like Omnibus Netcool - incident creation, IEM - hardware and software asset discovery, TADDM - CI discovery, and SaaS Service Portal.

2.5. Explain the methods and tools that support external integration ( ITIC, Integration

Framework, IBM Security Directory Integrator (previously TDI), etc) SUBTASK(S): 2.5.1. IBM Tivoli Integration Composer (ITIC)

2.5.1.1. ITIC is separately installed integration tool that imports data from external data sources into the Maximo database tables.

2.5.1.2. ITIC is used to import hardware and software data from a discovery tool

database into Maximo. 2.5.1.3. How to create and run an ITIC integration in general(create a database

source, mapping file, etc) 2.5.2. Automation Scripts

2.5.2.1. Automation Scripts can interact with the Maximo Business Objects Framework to create new functionality or extend existing functionality in ICD. These automation scripts are considered configurations and not customizations in ICD. Automation scripts can be started using multiple launching points and from every application and MBO. In addition it can be used to interact with external systems such as: WebSphere, command line interface, etc.

2.5.3. Security Directory Integrator (SDI) - (previously TDI) 2.5.3.1. SDI is used to create new integrations between ICD and other applications. It

supports multiple data formats (web servcies, database, file based, rest, etc) and can support complex data manipulation and mapping.

2.5.4. Representational State Transfer (Rest API) 2.5.4.1. Rest is a service that is called using HTTP Protocols. Rest API can be used to

query data or create new data in ICD. 2.5.5. Integration framework

2.5.5.1. The integration framework provides functionality of integrating application data with other applications, either within the enterprise or with external systems. 2.5.5.1.1. Load data files. Export data files. 2.5.5.1.2. Web services

enable real-time querying of product application data by an external application.

Call a external web services

Create reporting services for external reporting tools to consume.

2.5.6. Migration Manager 2.5.6.1. Use Migration Manager to migrate configuration content from one product

environment to another. MM does not migrate data. 2.5.6.2. Typically migrate configuration content from a development environment to a

test environment and then to a production environment. 2.5.6.2.1. To migrate the configuration content, you organize it into packages. 2.5.6.2.2. The packages go through a series of steps that make up the

migration process. 2.5.6.2.3. Some steps occur in the originating environment, called the source

environment, and some steps occur in the destination environment, called the target environment.

2.5.7. Other tooling and Integration Methods 2.5.7.1. OSLC, JMS, Database, File, Command Line, XML over HTTP(s).

Section 3 - Configure IBM Control Desk

3.1. Explain the security options including people and users for IBM Control Desk SUBTASK(S):

3.1.1. Summarize the differences between Users, People, Security Groups and Person

Groups and explain how they complement each other. 3.1.1.1. Users: Individuals who have the right to log into ICD and run its applications.

All Users are also People. A security context is maintained for each User that contains such information as the User’s password and the Security Groups to which the User belongs.

3.1.1.2. People: Individuals that are known to ICD and can be referenced in ICD object such as Tickets and Work Orders. Not all People will also be Users. Organizational, location and contact information is maintained for each Person.

3.1.1.3. Security Group: Used to define a broad set of authorizations and restrictions. For example, a Security Group defines the set of application access rights that accrues to a member of the group. Those rights can be unconditional or controlled by run-time conditions. Users can have read, insert, save, and delete access to an application. Security Groups can be used to define data restrictions at the Object, Attribute or Collection level. The application access of a security group is linked to site access. You can give a security group access to all sites, access to specific sites, or no access to sites. A User will be a member of multiple Security Groups and the User’s overall security context is calculated based on the combination of those groups. Each Security Group can also specify a Start Center page and/or an initial application to run for the logged in User.

3.1.1.4. Person Group: Provides a way to aggregate People into groups that can be the target of Workflow assignments and e-mail notifications. Person Groups can be assigned as the Owner Groups for Tickets and Work Orders. Person Groups support the ability to define Person delegates for the primary Person members of the Group. Person Groups can support chat queues and can be configured to support automated Ticket distribution.

3.1.2. Describe the options for ICD security configuration that are important decision points during installation. 3.1.2.1. Employ the application server and both LDAP for authentication and

user/group management. 3.1.2.1.1. One option is to administer perform User administration in a

directory server (i.e. LDAP Server). 3.1.2.1.2. The information from the directory server is automatically updated in

the ICD database by using a cron task to schedule the updates. The LDAP integration can also pass down Security Group membership for the Users administered by LDAP. However, Security Group administration (i.e. defining the authorizations and restrictions accruing to the group) is performed in ICD and Security Group membership assignments can also be performed within ICD. When User administration is controlled within LDAP, manual User administration within ICD is disabled. This option requires application security to already be enabled in the Web Server.

3.1.2.2. Utilize the application server and LDAP for authentication only (i.e. not also for user/group administration). 3.1.2.2.1. With this option, User and Security Group adminstration is both in

LDAP and in ICD. The LDAP/Web Server combination needs to

maintain sufficient user credential information so that it can authenticate users.

3.1.2.3. Perform user administration and authentication internally within ICD. With this option, a directory server is not required. 3.1.2.3.1. Users and Groups are manually administered within ICD; separately

from any corporate user data that is being maintained with the directory server.

3.1.3. Describe how the VMMSYNC cron task and LDAPSYNC cron task used to support application server security. 3.1.3.1. Cron tasks are controlled via the Cron Task Setup application. The application

determines how frequently a task is scheduled and can be used to specify input parameters that control the behavior of the cron task.

3.1.3.2. VMMSYNC- WebSphere Application Server-based data synchronization is governed by the federated repositories which are managed by Virtual Member Manager (VMM) and the VMMSYNC cron task.

3.1.3.3. LDAPSYNC- Oracle WebLogic Server-based data synchronization is managed by the LDAPSYNC cron task which synchronizes users and groups incrementally. Incremental synchronization can help with performance and planning.

3.1.3.4. The VMM and LDAPSYNC cron tasks fully synchronize all users and groups. 3.1.4. Describe how the single sign-on environment is supported.

3.1.4.1. When application server security is enabled, a single sign-on environment can be supported. This environment enables a user to provide one name and password to access multiple applications.

3.2. Perform the initial configuration which includes IT foundation data (organization,

sites, etc). SUBTASK(S): 3.2.1. Create Currency codes 3.2.2. Create Item Set and Company Set

3.2.2.1. Sets: groupings of information that a number of organizations can mutually see and access

3.2.2.2. Item Sets: are used for sharing items that are defined in the Item Master application

3.2.2.3. Company Sets: are used for sharing vendors and other external entities defined in the Company Master application

3.2.2.4. Each organization is associated with only one Company Set 3.2.2.5. Each organization is associated with only one Item Set 3.2.2.6. Item and Company Sets can be used by multiple organizations 3.2.2.7. At minimum, create one Item Set and one Company Set

3.2.3. Create General Ledger (GL) Clearing Account 3.2.3.1. At minimum, one GL account is required 3.2.3.2. Define the GL code format in Database Configuration application 3.2.3.3. After defining the GL code format, the database configuration will automatically

adjust all related objects that contains GL attributes with new maximum length of the GL code format. And when there is such change, applying Database Configuration change is required.

3.2.3.4. Create GL Component Maintenance code and GL account code in Chart of Accounts application

3.2.3.5. Review and Update the Validation Options in Chart of Accounts application 3.2.4. Create First Organization

3.2.4.1. Organization code has maximum 8 characters length, use the description field to enter a more meaningful organization name

3.2.4.2. It is possible to input up to two (2) base currencies 3.2.4.3. Select the pre-created Item Set and Company Set 3.2.4.4. Select one of the options for Default Item Status 3.2.4.5. Select one of the options for Default Stock Category 3.2.4.6. Select the GL Clearing Account 3.2.4.7. Set active and save the organization

3.2.5. Create a Site 3.2.5.1. A site is a subdivision of an organization that might track inventory and other

data separately from other sites. Certain site information is unique to the site and is not visible to other sites

3.2.5.2. A site does not necessarily correspond to a physical site or facility 3.2.6. Configure Organization related information

3.2.6.1. Configure auto numbering (e.g. Incident, Problem, Service Request) 3.2.6.2. Review/Modify Status of Ticket Application 3.2.6.3. Review/Modify System Settings

3.2.7. Configure Calendars and related settings in Organization setup 3.2.7.1. Create Calendar 3.2.7.2. Define/Apply Shift and Shift Pattern 3.2.7.3. Define/Apply Non Working Time (e.g. Public Holiday) 3.2.7.4. Review/Update Calendar usage in Organization's SLA Options.

3.3. Understand report administration, security and reporting capabilities. SUBTASK(S): 3.3.1. Search and navigate out of the box BIRT reports of IBM Control Desk Applications 3.3.2. Prepare reports for execution

3.3.2.1. Out of the box, ICD 7.6 comes with a set of BIRT and Cognos reports. It is also possible to import additional reports. The “Import Report” action within the “Report Administration” application can be used to import BIRT reports into ICD. Both a Report Design File and a Report Resource file must be provided in order to import the BIRT report.

3.3.3. Initialize and preview individual report in Report Administration application 3.3.3.1. Before a report is enabled for running, a request page must be generated for

the report. This is accomplished using the “Generate Request Page” function within the “Report Administration” application.

3.3.4. Setup Report Security 3.3.4.1. 'Report Level Security' defines the permissions to authorize Security Groups to

access individual report 3.3.4.2. 'Application Level Security' defines the permission to authorize Security

Groups to access a sets of reports for a specific Application 3.3.4.3. 'All Application Security' is an action that provides a simple way to enable and

remove access to all reports in all applications for a Security Group. Access

can be given to all BIRT reports, to all Cognos reports, to all custom reports, or to some combinations of the three

3.3.5. Review Group Security Permissions: 3.3.5.1. Use 'View Group Security' action to review all Application Level permissions

granted to a Security Group 3.3.6. Setup report limits for Security Groups:

3.3.6.1. Use 'Set Security Group Limits' action to configure record limits for Security Groups.

3.3.7. Configuration of Report Object Structure (ROS) 3.3.7.1. ROS are hierarchies of database objects joined together via relationships. 3.3.7.2. ROS are created in Object Structure application. There are a number of out of

the box ROS in IBM Control Desk 3.3.7.3. ROS configuration contains one or more source objects that have parent/child

relationship 3.3.7.4. ROS Security needs to be configured from Report Administration application to

grant access for specific Security Groups 3.3.7.5. Once ROS are configured, they can be used for Query Based Reporting (QBR)

to generate AdHoc reports 3.3.8. Configuration of AdHoc Report Expression Library from Report Administration

application 3.3.8.1. AdHoc Report Expression Library contains sets of SQL expressions that can

be used when creating AdHoc reports. This library can serve for storing frequently used SQL expression and it can also function as a guidance for end user when creating SQL expression for AdHoc report.

3.4. Explain the IBM Control Desk logging options. SUBTASK(S): 3.4.1. General location where ICD exports all of its logging: WebSphere and Control Desk

logs 3.4.1.1. Control Desk logging -

\IBM\WebSphere\AppServer\profiles\<profilename>\maximo\logs 3.4.1.2. WebSphere Logging -

\IBM\WebSphere\AppServer\profiles\<profilename>\logs\<JVM> 3.4.2. Where in ICD is the logging application located and general setup information

3.4.2.1. Goto -> System Configuration-> Platform Configuration-> Logging 3.4.2.2. Parent and Child logging ( CronTask-> LDAPSync, Email Iistener, CCMDB ->

PMPCommon, PMPUIWidget, etc) 3.4.3. How to create additional log files for specific logging applications to debug issues 3.4.4. Identify Log Levels.

3.4.4.1. ERROR – Logs messages indicating errors in the application functionality 3.4.4.2. DEBUG – Logs messages that are useful in debugging 3.4.4.3. FATAL – Logs very severe errors messages 3.4.4.4. INFO – Logs informational messages 3.4.4.5. WARN – Logs messages indicating harmful situations in functionality

3.4.5. Additional Actions in Logging - Apply Settings, Manage Maximo Root Logger, etc 3.5. Summarize the system configuration options (system properties, cron tasks, etc).

SUBTASK(S): 3.5.1. Setup outbound email configuration in system properties

3.5.1.1. Update SMTP Server value in system properties: mail.smtp.host 3.5.1.2. Configure administrator email address in system properties: mxe.adminEmail 3.5.1.3. Verify SMTP server name server resolution from IBM Control Desk server 3.5.1.4. Verify SMTP connection to SMTP server

3.5.2. Review and update common global system properties: 3.5.2.1. mxe.hostname : input with ICD server published URL. One of the usage is

being used for 'HOSTNAME' keyword in Communication Template 3.5.2.2. mxe.useAppServerSecurity : Application Level Security flag, it is to be used in

conjunction with the J2EE middleware (WebSphere/WebLogic) security configuration

3.5.2.3. mxe.AllowLDAPUsers : a flag to indicate whether LDAP users are allowed to authenticate into ICD if the user record has not been created. It usually being used in a deployment that allow Self Registration

3.5.2.4. mxe.LDAPUserMgmt : a flag to indicate whether user records are managed by LDAP. This flag requires mxe.useAppServerSecurity=1.

3.5.2.5. After applying the system properties changes, 'Life Refresh' action can be used to make the new values take effect. There are system properties cannot use 'Life Refresh', they will need the ICD application restart to take effect.

3.5.3. Review and update instance system properties: 3.5.3.1. instance system property applies the property value only on the specified

server 3.5.3.2. This type of system property is usually used in clustered deployment

3.5.4. Modify Attachment (DOCLINK) directory 3.5.4.1. Create the intended doclink directory 3.5.4.2. Update HTTP Server configuration to add the new doclink URL 3.5.4.3. Update doclink related parameters in system properties with the new path and

URL 3.5.4.4. Update Attachment Library Folder with new doclink path 3.5.4.5. Verify the new doclink path from IBM Control Desk applications

3.5.5. Configure Email Listener 3.5.5.1. Create Email Listener using the provided external email address listener and

out of the box Email Processing workflow (e.g. MFMAILRCV) 3.5.5.2. Configure Email Listener with Secure Protocol 3.5.5.3. Configure Security Settings of Email Listener

3.5.6. Configure Email Interaction Setup 3.5.6.1. Setup Email Interaction for Status Update / Workflow Assignment 3.5.6.2. Create / Modify Communication Template for Email Interaction usage 3.5.6.3. Create / Modify Escalation for Email Interaction Notification 3.5.6.4. Review and Update System Properties for Email Interaction Setup

3.5.7. Configure Organization Settings 3.5.7.1. Review and Update Work Type under Work Order options:

3.5.7.1.1. Configure the Work Type for Work Order related applications such as ACTIVITY, CHANGE, RELEASE

3.5.7.1.2. Define the Start and Complete status for each Work Type configuration

3.5.7.2. Review and Update Workflow Options for Service Catalog

3.5.7.2.1. ICD provides out of the box workflows for Service Catalog. If Service Catalog implementation uses a custom workflow, the new workflow should be updated here

3.5.7.2.2. The default 'Line Manager Approval' workflow and default 'Fulfillment Manager Approval' workflow in service catalog are defined here

3.5.7.3. Review and Update SLA Options: 3.5.7.3.1. Specify whether SLA Hold feature will be used for the organization 3.5.7.3.2. Specify Single or Multiple SLA permitted 3.5.7.3.3. Specify Multiple SLA options 3.5.7.3.4. Enable / Disable the usage of Calendar when calculating SLA

escalation point 3.5.7.4. Review and Update Status of Ticket Application

3.5.7.4.1. Specify initial ticket status for Incident, Problem, and Service Request application for a specific site

3.5.7.5. Review and Update System Settings in Organization application 3.5.7.6. Review and Update CI and Asset Synchronization 3.5.7.7. Review and Update Service Address Options

3.5.8. Cron Task Setup 3.5.8.1. Review and Update Cron Tasks 3.5.8.2. Update Cron Task Schedule 3.5.8.3. Activate/Deactivate and Reload Cron Task.

3.6. Explain how workflows and escalations can be configured. SUBTASK(S): 3.6.1. Describe the purpose of ICD Workflows

3.6.1.1. Workflow provides a means of electronically modeling business processes so that they can be applied to records.

3.6.1.2. Using Workflow, it is possible to manage the movement of a record through a process from start to finish. Individuals can be instructed to act on records, specify delegates when workers are unavailable, ensure that individuals act in a timely manner, and ensure that an audit trail exists for each record and process.

3.6.2. Illustrate the main Workflow configuration elements 3.6.2.1. Workflow processes are configured using a graphical UI that supports a small

set of node types that can be connected in different combinations to model a desired business process model.

3.6.2.2. There are eight Workflow node types 3.6.2.2.1. Start- Indicates the single starting point for a Workflow process 3.6.2.2.2. Conditional- Provides binary decision choices within a process. 3.6.2.2.3. Interaction- Guides user interaction with a Workflow. Can be used to

do things such as pop up an application action panel, pop up a message panel or change UI focus to another page with an application or to a different application entirely.

3.6.2.2.4. Manual Input- Used to pop up a multiple choice panel that permits the user to guide how the Workflow process should proceed.

3.6.2.2.5. Task- Used to make assignments to users. These assignments appear in the user’s Inbox within the user’s Start Center

3.6.2.2.6. Wait- Enable a Workflow process to suspend execution, waiting for important external asynchronous events such as record updates and status changes.

3.6.2.2.7. Sub-process- Permits large Workflows to be decomposed into smaller manageable units.

3.6.2.2.8. Stop- Indicates the termination point of a Workflow process. There can be multiple Stop nodes defined within a Workflow process.

3.6.2.3. Actions and notifications can be specified to execute when certain nodes are executed or when certain connectors are traversed. Workflow processes can be triggered in a variety of ways.

3.6.3. Describe the purpose of ICD Escalations 3.6.3.1. Escalations are used to support asynchronous processing models. They can

be used for a variety of purposes, such as: 3.6.3.1.1. To ensure that critical tasks, such as those defined in service level

agreements, are completed on time. 3.6.3.1.2. To change the status or owner of a record (e.g. auto-close a ticket

that was in Resolved state for a sufficient period of time). 3.6.3.2. A single Escalation can define multiple independent Escalation Points. 3.6.3.3. Escalations can perform Actions or send notifications when a record reaches a

defined escalation point. 3.6.4. Illustrate the main Escalation configuration elements

3.6.4.1. “Applies To”: Escalations are defined to operate in the context of particular object types

3.6.4.2. “Schedule”: Defines how frequently the Escalation will be executed and the global condition is evaluated.

3.6.4.3. “Condition”: The global condition of the Escalation that is evaluated every time that the Escalation is executed.

3.6.4.4. “Escalation Points”: Multiple independent Escalation Points can be defined within a single Escalation. 3.6.4.4.1. Each Escalation Point has its own specific Condition. When the

global condition of an Escalation evaluates to true, the conditions of each of its Escalation Point conditions is also evaluated.

3.6.4.4.2. If the Escalation Point condition evaluates to true, then any Actions and notifications that are associated with the Escalation are executed.

3.6.4.4.3. There is a “Repeat?” flag associated with each Escalation Point. If the flag is not set, then the Actions and notifications associated with the Escalation Point can be triggered a single time. This is a critical flag, because often one only wants an Escalation Point to trigger a single time.

3.6.5. Describe how Actions and Communication Templates support Workflow and Escalation processing. 3.6.5.1. Actions: Provide access to a variety of built-in capabilities that includes the

ability to 3.6.5.1.1. Initiate an application action (e.g. create an Incident or apply a

Response Plan) 3.6.5.1.2. Change the status of a record 3.6.5.1.3. Set the value of an attribute within a record 3.6.5.1.4. Execute an Automation Script or a Custom Class

3.6.5.1.5. Group together multiple Actions that will execute in sequence 3.6.5.1.6. Execute a command line executable (i.e. external program or script)

3.6.5.2. Actions can triggered from within Workflow connectors and within Escalation Points.

3.6.5.3. Communication Templates: Used to standardize frequently used email notifications. The notifications can be automatically triggered from within Workflow nodes and connectors and from within Escalation Points.

3.6.6. Demonstrate understanding of the key elements of Actions. 3.6.6.1. “Object”: Actions are defined to operate in the context of particular object types

(e.g. Work Orders, Assets or Service Requests). 3.6.6.2. “Type”: Defines the type of the Action (e.g. Change Status, Set Value,

Application Action or Action Group). 3.6.6.3. “Parameter/Attribute”: For certain Action types, defines the target of the Action.

For example, for the Set Value type, this defines which object attribute is to be modified.

3.6.6.4. “Value”: Specifies how the target of the Action is to be effected. For example, for the Create Work Order (Application Action) type, this can be used to optionally specify the Job Plan to be applied when the Work Order is created.

3.6.6.5. Members: For the Action Group type, this specifies the sequence of primary Actions to be performed when the Action Group is executed.

3.6.7. Demonstrate understanding of the key elements of Communication Templates. 3.6.7.1. “Applies To”: Communication Templates are defined to operate in the context of

particular object types. 3.6.7.2. “Accessible From”: It is possible to specify that a Communication Template is

only executable from within the context of a Workflow or an Escalation or from both.

3.6.7.3. Template Details”: This is where the Subject and Message body of the notification is defined. The Communication Template application supports a Rich Text Editor for use in the construction of the message body.

3.6.7.4. “Recipients”: The “Send From:”, “To:”, “Cc:” and “Bcc:” portions of a notification can be defined in a variety ways (i.e. by Role, by specific Person, by specific Person Group and by specific E-mail Address).

3.6.7.5. “Attachments”: Optionally, attachments can be specified that will be sent out with a notification.

3.6.8. Illustrate understanding of other ICD System Configuration objects that support Workflows, Escalations, Actions and Communication Templates. 3.6.8.1. cron Tasks: Behind-the-scene jobs that run automatically and on a fixed

schedule. The periodic evaluation of Escalations is controlled by cron task scheduling.

3.6.8.2. Domains: Used to constrain the values that can be assigned to a record attribute. A special type of Domain (Crossover Domain

3.6.8.3. Roles: Provides a variety of ways to specify the senders and recipients of e-mail notifications and the recipients of Workflow Task assignments.

3.6.8.4. Automation Scripts: A very flexible way to code complex behavior. Automation Scripts can be packaged with Action launch points.

3.7. User must have working knowledge of the database and application before

performing Application changes or dB updates.

SUBTASK(S): 3.7.1. The Application Designer is an application where you can drag and drop components

to modify an application without editing any code. You can also copy and create applications and restrict access to specific components or to an entire application.

3.7.2. With the Application Designer, you can perform the following common modifications to the user interface of a selected application: 3.7.2.1. Moving fields and sections 3.7.2.2. Adding new fields, tabs, and tables with columns and rows

3.7.2.2.1. You can also perform the following more advanced functions with the Application Designer:

3.7.2.2.2. Creating or duplicating applications 3.7.2.2.3. Defining signature options to restrict access to a component or to a

specific application component 3.7.2.3. Editing the toolbar or the Select Action menu.

3.7.3. You can create an application or duplicate an existing application with the Application

Designer. It can be necessary to perform some of the following additional activities to fully-enable a new application: 3.7.3.1. Create database tables and columns 3.7.3.2. Define user access to the application 3.7.3.3. Develop Java™ code 3.7.3.4. Develop workflow processes

3.7.4. Describe the capabilities and use of Application Designer for the configuration and UI changing of IBM Control Desk. 3.7.4.1. Through the use of Application designer and DB configuration it is possible to

ensure a easy to use, and positive user experience, by setting the application fields up in a flow or pattern of use for heavy use cases.

3.7.4.2. When using Application designer or db configuration it is important to consider the customer circumstances for when a UI needs to be changed, fields deleted or added.

3.7.4.3. Using App designer and db configuration it is possible to create a new application to ensure the tool set meets the overall customer requirements.

3.7.4.4. It is important to use appropriate controls when using application designer. Controls are predefined components, such as text boxes, buttons, and tabs, that are used to build the application user interface. In the Application Designer, you can select a control from the Control Palette and drag it to the workspace to add it to the user interface.

3.7.4.5. App designer and DB config work in collaboration with each other to ensure a knowledgeable/skilled resource can set up or configure IBM Control Desk to meet the business needs of the customer, through a simple UI.

3.7.4.6. App designer and DB configuration inter-connect with other tooling such as integration framework, domains, Roles, actions, workflow designer to ensure effective delivery of function and capability in the UI for customer requirements.

3.7.4.7. Use of the Database Configuration application to create or change objects and attributes, and to customize the database. An object is a self-contained software entity that consists of both data and functions to manipulate data. Most applications are associated with one main object and other related objects.

3.7.4.8. When you use the Database Configuration application, you interact at the business object level. Internally, the application determines the actions to take on the database tables to support the needs of business objects.

3.7.4.9. A database table can store several objects, each object having different business rules. For example, the TICKET table defines Incident, Problem, and Ticket business objects, which are defined as database views. In addition, a business object (view) can span more than one database table. Views represent objects that can span multiple tables.

3.7.4.10. With the business object layer, the system tables that must not be modified are not editable on the user interface but you, an administrator, can view them.

3.7.4.11. When changing the database, for example, when creating or deleting objects, attributes, or indexes, changes are stored in secondary tables. The changes do not take effect until you configure the database. It is important to back up your data before configuring the database.

3.7.4.12. Describe the functionality and capabilities of DB configuration for the updates and changes to IBM control Desk.

3.7.4.13. The db configuration capabilities enable you to create or change objects and attributes, and to customize the database of IBM Control Desk. An object is a self-contained software entity that consists of both data and functions to manipulate data.

Section 4 - Usage of IBM Control Desk

4.1. Demonstrate knowledge of basic navigation and UI usage. SUBTASK(S): 4.1.1. Navigation in ICD UI

4.1.1.1. Open various Applications from GoTo menu 4.1.1.2. Open recent Applications 4.1.1.3. Open Start Center Home 4.1.1.4. Open Bulletin Board notification 4.1.1.5. Open various Reports 4.1.1.6. Open User Profile Information (Default / Personal / Password Information) 4.1.1.7. Open System Information from Help menu

4.1.2. Navigate the application user interface 4.1.2.1. Open an application 4.1.2.2. View a list of records 4.1.2.3. Select an action 4.1.2.4. Create bookmarks 4.1.2.5. Use keyboard shortcuts

4.1.3. Search records 4.1.3.1. Perform basic searches by using the search tool bar 4.1.3.2. Perform advanced searches by using SQL 'Where Clause' or 'More Search

Fields' 4.1.3.3. Use Wildcards and operators or search with exact value 4.1.3.4. Save search as Query 4.1.3.5. View and Manage saved Queries

4.1.4. Navigation in Start Center

4.1.4.1. List type of portlets: 4.1.4.1.1. Quick Insert 4.1.4.1.2. Bulletin Board 4.1.4.1.3. Favorite Applications 4.1.4.1.4. Inbox / Assignments 4.1.4.1.5. KPI graph 4.1.4.1.6. KPI List 4.1.4.1.7. Report List 4.1.4.1.8. Result Set

4.1.4.2. Differentiate the User's Start Center and Start Center Template configuration 4.1.4.3. Refresh User's Start Center from Template 4.1.4.4. Change Start Center Content Layout 4.1.4.5. Edit Portlet content of each type of portlets 4.1.4.6. Show / Hide Start Center from Security Group

4.2. Perform Service Desk and Service Catalog Management. SUBTASK(S): 4.2.1. Perform Service Request Management

4.2.1.1. Use the “Create Service Requests” application to create and submit a Service Request record. Key data to specify in the new Service Request includes: 4.2.1.1.1. “Source” (e.g. PHONECALL or EMAIL). 4.2.1.1.2. “Reported By” person- specifying the Reported By person will pull in

other details about that person into the Service Request. 4.2.1.1.3. “Affected Person”- can be different from the Reported By person 4.2.1.1.4. “Summary”- short descriptive title for the request. 4.2.1.1.5. “Details”- longer narrative about the request. 4.2.1.1.6. “Classification”- specifies the category of Service Request (from a

Classification taxonomy) and can drive subsequent processing logic. 4.2.1.1.7. “Customer”- if the Reported By person is associated with a specific

customer. 4.2.1.1.8. “Reported Priority”- the Reported By person’s sense of the priority of

the request. This is distinct from the “Internal Priority” that will be specified by the agent.

4.2.1.1.9. “Custom Request”- specifies a Ticket Template that (when applied) will fill in portions of the Service Request.

4.2.1.2. Assign Ownership of the Service Request 4.2.1.2.1. Service Requests can have an Owner Group and a specific Owner.

Setting an Owner Group and setting Service Request status to “QUEUED” typically indicates that the Service Request has been placed on a queue and is waiting for some member of the Owner Group to take explicit ownership.

4.2.1.3. Drive the Service Request through its life cycle 4.2.1.3.1. Key Service Request Status values indicate the relative position of

the Service Request within it processing cycle.

NEW- The initial state of a Service Request.

QUEUED- Waiting for explicit ownership.

INPROG- Owner has been assigned and the request is being

worked.

PENDING- No work is currently being performed on the Service Request because the owner is waiting for some event outside of the owner’s control.

SLAHOLD- Similar to PENDING; but key difference is that the Service Desk team should not be held responsible (i.e. against any Service Level Agreements) for this particular wait. Typically, this means that the Service Request owner is waiting for some response or action by the requester.

RESOLVED- The Service Request owner believes that the request has been adequately fulfilled. However, it is possible that the requester may not agree.

CLOSED- A reasonable amount of time has passed since the Service Request was resolved, so the Service Request can be closed. Once closed, the Service Request can (mostly) no longer be modified.

4.2.1.4. Tools that are used to automate portions of Service Request processing: 4.2.1.4.1. Ticket Templates- A specific Ticket Template can be applied to a

Service Request. When this occurs, particular Service Request attribute values are filled in from the template and (optionally) Activities (a form of Work Order) can be created and associated with the Service Request.

4.2.1.4.2. Response Plans- When the “Apply Response Plan” action is performed, ICD looks to find the best matching Response Plan (if any) to apply to the Service Request. The application of a Response Plan can set different Service Request attribute values and it can also trigger a variety of Actions that are applied against the Service Request.

4.2.1.4.3. Service Level Agreements (SLAs)- When the “Apply SLA” action is performed, ICD looks to find the best matching SLA (if any) to apply to the Service Request. The application of an SLA can set different “target” values for the Service Request (e.g. “Target Start” and “Target Finish”). The SLA can also initiate an Escalation that tracks the processing of the Service Request against these target values.

4.2.1.4.4. Workflow- Workflow processes can be initiate that drive the manner in which the Service Desk agents process the Service Request.

4.2.1.4.5. Escalations- Can be used to make periodically evaluated decisions about the Service Request (e.g. to automatically close a Service Request after it has been in RESOLVED status for a specified amount of time).

4.2.1.4.6. Automation Scripts- Can be triggered at key points (e.g. when the Service Request state is saved or when particular Service Request attributes are modified) to enforce required business policies against the Service Request. Automation Scripting is and advanced configuration that can support specialized operations.

4.2.1.5. Work Management 4.2.1.5.1. Service Requests are a form of “ticket” that indicates something that

is being requested. If the work required to fulfill the request is

sufficiently complex or is often repeated, Work Order can be created against the Service Request that are used to track the actual work performed.

4.2.1.5.2. Work Orders, Activities and Changes can all be created against a Service Request. Work Orders and Activities are highly similar; but are treated a bit differently in the “Service Requests” application UI. Changes are typically managed by a much more controlled Change Management process.

4.2.1.6. Related Records 4.2.1.6.1. The “Related Records” tab page of the “Service Requests”

application lists all the tickets and Work Orders that are related to the Service Request.

4.2.1.6.2. When another ticket or Work Order is created from a Service Request, that “Originator/Follow-up” relationship is automatically added to the “Related Records” page.

4.2.1.6.3. It is also possible to manually create “lighter weight” relationships between a Service Request and other tickets or Work Orders. These relationships are provided so that the Service Request will have a “memory” of those tickets or Work Orders. That memory can be useful during later inspections of the Service Request; when Service Desk personnel attempt to understand why the Service Request was processed in a particular manner.

4.2.1.7. Service Request Logs 4.2.1.7.1. Work Log- Provides a repository of log entries that permit Service

Desk agents to provide history about how a Service Request was processed. It is possible to indicate whether a Service Request Work Log entry will be visible to the requester (via the Service Request Self Service applications).

4.2.1.7.2. Communication Log- Logs outgoing and incoming e-mail notifications that are associated with the Service Request.

4.2.1.7.3. Audit History Log- It is possible to enable e-audit logging for specific Service Request attributes. If this is done, all modifications to those attributes will be logged into the A_TICKET audit log table. It is possible to extend the “Service Requests” application UI to display this information.

4.2.1.8. Solutions 4.2.1.8.1. Provide a knowledgebase that can assist Service Desk agents to

understand how best to process a Service Request. 4.2.1.8.2. Service Desk agents can provide feedback (to the Knowledge

Manager) about the effectiveness of different Solutions. 4.2.1.9. Customer Surveys

4.2.1.9.1. ICD supports a Customer Survey facility. A repository of questions can be compiled and surveys can be constructed containing subsets of those quests.

4.2.1.9.2. Service Request automation can determine when surveys should be e-mailed to Service Request requesters.

4.2.1.9.3. ICD collects and aggregates the survey responses that are returned by end users.

4.2.2. Perform Service Catalog Management

4.2.2.1. Service Catalog requests can be made in a variety of ways: 4.2.2.1.1. Using the Self Service Center application 4.2.2.1.2. Using the Offering Catalog application 4.2.2.1.3. From the self-service user portion of the Service Portal

4.2.2.2. Service Request generation- When the Service Catalog requester is creating a Service Catalog order, the requester is working with a Service Catalog Request (PMSCCR) object. When the Catalog Request is submitted, a Service Request is generated and the details from the Catalog Request is copied into the Service Request.

4.2.2.3. Service Request approval- Typically, Service Catalog requests require some form of approval. The Service Catalog Offering object supports the option of configuring of two separate approval Workflows: 4.2.2.3.1. Line Management approval Workflow- typically used to enforce

financial and organizational policies 4.2.2.3.2. Fulfillment Management approval Workflow- typically used to

provide a way for the request fulfillment organization to veto a request because the organization is not currently capable of doing so.

4.2.2.3.3. However, strictly speaking, these two approval Workflows can be used in whatever way Service Catalog management believes best

4.2.2.4. Request Fulfillment- 4.2.2.4.1. There are three types of Service Catalog Offerings:

Service Request- These are Offerings that operate by generating a Service Request from the Catalog Request object.

Action- These Offerings operate by either initiating a specific Workflow or by performing a Launch in Context to an external URL. This Offering type is provided to simplify linkage to existing service facilities.

Descriptive- These Offering do not perform any specific request fulfillment. This Offering type is provided as a simple way to advertise existing services that are entirely handled in a manual fashion. The Descriptive Offering simple provides some narrative text that indicates how the requester can locate the service provider.

4.2.2.4.2. After a Service Request (type) Offering order has been approved, it can either be processed as a Service Request or a Work Order or Change can be generated from the original Service Request.

4.2.2.4.3. Typically, an “Apply Response Plan” action is executed against the approved Service Request. The Response Plan that is applied can structure how the fulfillment of the request will proceed.

4.2.3. Perform Incident Management 4.2.3.1. Incident Management is aimed at dealing with Service Level degradations or

outages. Many aspects of it are similar to what was previously described for Service Requests.

4.2.3.2. Incident creation- Incidents can be created from Service Requests. They can also be manually created when a Service Desk agent or Operations person detects some sort of service failure. They also are automatically created by

integrations with trusted monitoring applications (e.g. Netcool Omnibus and Impact).

4.2.3.3. Global Incidents- Often, Incidents are tagged as “Global Issues”. Service Requests (and other Incidents) can be associated with a global Incident. When this relationship exists, the global Incident exerts influence on the related tickets. Status changes in the global Incident are passed down to the related tickets. Work Log entries are copied to the related tickets. In this manner, when the global Incident is resolved, all the related tickets are also resolved; saving the Service Desk agents the work to separately update the related tickets.

4.2.3.4. Failure Reporting- One characteristics of Incidents that is not seen in Service Requests is that the Service Desk agent can report the proximate cause of the service outage within the Incident.

4.2.4. Perform Problem Management 4.2.4.1. Problem Management is aimed uncovering the root causes of service outages.

Like Incidents, many aspects of Problems are similar to what was previously described for Service Requests.

4.2.4.2. Problem creation- Problems may be directly created from Incidents (or from Service Requests). Problems may also be created as a result of independent analysis of Incident patterns. Service desk management may identify a pattern of repeated service failures and decide to create a Problem in order to investigate possible root causes.

4.2.4.3. Failure reporting- Like Incidents, Problems provide a way in which to log the causes of service failures.

4.2.4.4. Change integration- Often, once the root causes of a Problem are understood, Changes (or just simple Work Orders) may be created off the Problem to manage the work required to remediate the root causes.

4.2.5. Illustrate the capabilities of the Self Service Center 4.2.5.1. The ICD 7.6 Self Service Center is an application that provides an attractive

and user friendly environment for the self-service user. 4.2.5.2. It offers the self-service user the following options:

4.2.5.2.1. Search for Solutions, Offering and Quick Inserts (i.e. Service Requests that will have a particular Ticket Template applied)

4.2.5.2.2. Browse the Solutions database 4.2.5.2.3. Request a New Service- Can be used to request a Service Catalog

Offering 4.2.5.2.4. Report an Issue- Open a Service Request in order to report the

issue 4.2.5.2.5. Frequent Requests- Provides quick access to frequently requested

Services and Issues 4.2.5.2.6. Chat interface- Quick access to the chat queues supported by the

Service Desk team 4.2.5.2.7. “My News”- Access to public Bulletin Board entries 4.2.5.2.8. “My Requests” POD- Summarizes the user’s outstanding requests

and offers access to individual requests 4.2.5.2.9. “My Assets” POD- Summarizes the Assets owned by the user and

offers access to the details of each Asset 4.2.6. Summarize the purpose of the Service Portal

4.2.6.1. IBM’s Service Portal may be used in conjunction with any on-cloud/SaaS based hosted deployed system or any Enterprise/On-Premise based system.

4.2.6.2. The traditional methods and UIs for accessing and using the self-service and ticketing start centers remain intact and may be used as well. The ICD Service Portal offers standard browser navigation features and provides keyboard shortcuts to optimize the user experience.

4.2.6.3. The IBM Control Desk Service Portal can be accessed on a mobile device, such as a tablet or mobile phone.

4.2.6.4. The Service Portal provides separate environments for self-service users and for Service Desk agents..

4.2.6.5. Administrators must configure IBM Control Desk to grant users access to the appropriate data for their respective role.

4.2.7. Describe how Service Desk agents can utilize the Service Portal 4.2.7.1. The Service Portal that was introduced with ICD 7.6 provides an alternative

Service Desk agent application UI. It runs in a separate execution environment from ICD, but uses REST integration calls to access the ICD database tables.

4.2.7.2. Out of the box, the Service Portal for Service Desk agents supports the creation and management of Incidents. However, it can be configured to create and manage Service Requests instead.

4.2.7.3. Compared to the “Service Requests” and “Incidents” applications, the Service Portal for Service Desk agents provides a much more limited and simpler to use ticket processing environment. It permits Service Desk agents to do the following sorts of things with a ticket: 4.2.7.3.1. Specify a Summary and Description for the ticket 4.2.7.3.2. Specify the requester of the ticket 4.2.7.3.3. Select the team (i.e. Owner Group) and Owner of the ticket 4.2.7.3.4. Control the status of the ticket 4.2.7.3.5. Set the “Severity” (i.e. Internal Priority) of the ticket 4.2.7.3.6. Manually set a target for the “Resolve By” date for the ticket 4.2.7.3.7. Log entries within the “Activity Log” (i.e. Work Log)

4.2.7.4. Among other things, Service Portal for Service Desk agents does not support the running of Workflows against the Incident or Service Request.

4.2.8. Describe how Self Service Users can utilize the Service Portal 4.2.8.1. The Service Portal for Users provides the following self-service choices:

4.2.8.1.1. “Report Issue”- Create an Incident (or Service Request; if that is how the portal is configured)

4.2.8.1.2. “My Tickets”- View tickets previously opened by the user 4.2.8.1.3. “Chat”- Open a chat session with a Service Desk agent 4.2.8.1.4. “Submit Request”- Provides access to the Service Catalog offerings

(in the UI format as elsewhere) 4.2.8.2. Reporting Issues- A very simple UI is supported. Only the Reporting User and

Ticket Summary fields are required. The optional Details field supports a Rich Text Format editor and the user can easily drop formatted text into the field. Files can also be attached to the issue.

4.2.8.3. “My Tickets” screen- The “My Tickets” page presents a list of tickets opened by the user. The list can be searched by ticket number of ticket summary. Clicking of a row in the list opens a particular ticket. The ticket details screen includes the following information: 4.2.8.3.1. Details that the user previously entered into the ticket. 4.2.8.3.2. Current ticket status.

4.2.8.3.3. Ticket “comments” (i.e. Work Log entries). The user can add additional comments to the ticket and these comments will be seen by Service Desk agents that work the ticket.

4.2.8.3.4. Attachments. The user can also add additional attachments to the ticket.

4.2.8.3.5. The “My Tickets” screen permits the user to cancel an outstanding ticket.

4.2.8.3.6. It also permits the user to verify a resolved ticket. If the resolution is rejected, the user must provide an explanation for why the resolution was rejected.

4.3. Demonstrate knowledge of managing IT hardware and software assets. INPUTS/DEPENDENCIES: SUBTASK(S): 4.3.1. As an asset manager or resource can manage IT assets (hardware and software)

through their life cycle of: Plan, Acquire, Deploy, Maintain and Retire, this is achieved through the various functions of : 4.3.1.1. Streamlined process for purchasing and receiving of IT assets 4.3.1.2. Track all IT assets, licenses, locations, work and changes for the IT assets. 4.3.1.3. Ensure better control of IT software license cost by reducing the likelihood of

overbuying or incurring fines due to under licensing of software 4.3.1.4. Record and manage all IT contracts for software licenses, hardware, leases,

warranty, and maintenance 4.3.1.5. Create and enforce technology standards by defining templates of standard

asset requests 4.3.1.6. Establish charge-backs using managed data with Service Provider 4.3.1.7. Reconcile assets actually deployed with authorized assets (those purchased

and under contract) 4.3.2. Utilizing IBM Control Desk you can

4.3.2.1. Establish Asset item master standards for both tracking and requesting. 4.3.2.2. Specify and enable refresh cycles and processes for IT assets. 4.3.2.3. Update and control the end-of-life process and details to ensure assets are

removed from the infrastructure effectively and the Control Desk data is accurate.

4.3.2.4. Associate users, custodians and groups to IT hardware and allocate licenses to hardware, persons, locations and others to ensure the asset portfolio is maintained and current.

4.3.3. IT Assets require IMAC (install, move, add, change activities) these are managed using WorkOrders. 4.3.3.1. License allocations occur using the work order planning and actuals tab to

ensure the license is “booked” and allocated to the appropriate resource? 4.3.3.2. Hardware assets are assigned and allocated, through the use of the work

order. Operations assets such as Servers and network equipment can also be put into service through the use of change records to ensure control and the change process is managed.

4.3.3.3. Control Desk allows change or work orders to be created to support the fulfillment or requesting process for asset and licenses.

4.3.4. IT Asset management interlocks to other processes and capabilities in IBM Control Desk such as Service desk, incident, problem, change, and configuration mgmt. 4.3.4.1. Issues or troubleshooting a user issue when it is associated to an asset or

License, can be enhanced through associating the asset or license to the incident, service request … so that the user can navigate and review asset or software data (authorized or discovered) to ensure faster time to resolution.

4.3.4.2. Associating assets and Configuration items allows the asset and operations teams to ensure accurate inventory controls, effective change processes and better management of resources and time.

4.3.4.3. Assets and Configuration items are created and support the full processes such as Service Request, Incident, problem change and release. As well as the full life cycle of asset/software management and the enablement and support of configuration management.

4.3.5. Asset requests and license management will be enabled to optimize the asset management process itself as well as all other supporting processes. 4.3.5.1. IT assets are often a common requested item through the service catalog

therefore it is key the processes and procedures of asset mgmt support and intertwine to the delivery of services of the catalog.

4.4. Demonstrate knowledge of Configuration Management, Change Management, and

Release Management using IBM Control Desk. SUBTASK(S): 4.4.1. requests from other parts of the IT organization and from other core service

management activities and processes within IBM Control Desk. 4.4.1.1. Asset management can request CI creation, CI updates, CI audits, and CI

lifecycle changes 4.4.1.2. Change Management may request CI creation or promotion before

implementing a change 4.4.1.3. Change Management may request CI verification after change implementation 4.4.1.4. Asset management can automatically create generic CIs when assets are

created 4.4.1.5. Asset management can automatically update key attributes based on Asset

and CI synchronization 4.4.1.6. Change management can automatically update CI attributes after a successful

change implementation 4.4.2. Configuration items are components that need to be managed in order to deliver an IT

Service. 4.4.2.1. Information about each CI is recorded in a configuration record within the

configuration management system and is maintained throughout its lifecycle by configuration management.

4.4.2.2. CIs are under the control of change management. 4.4.2.3. CIs typically include IT services, hardware, software, buildings, people, and

formal documentation such as process documentation and SLAs. 4.4.2.4. The same resources are often represented as both an asset and a

configuration item. 4.4.2.5. The asset is used to manage financial, contractual, and logistical information,

whereas the CI is used to manage the configuration & relationships of the resource including planned and unplanned changes.

4.4.3. IBM Control Desk stores both active (actual) and authorized configurations - for both assets and CIs - in the CMDB, and provides facilities to promote and synchronize the two representations.

4.4.4. IBM Control Desk enables linkage of (top-level) CIs and assets in several ways. 4.4.4.1. Automatically, through GUIDs assigned at import (from Tivoli Integration

Composer). The GUID for a specific resource is assigned based on naming attributes, so the asset and CI records for the same resource will have the same GUID.

4.4.4.2. Automatically, through the periodic execution of a reconciliation task that compares specific, unique attributes (for example serial number) of the CI and asset records to identify related records.

4.4.4.3. Manually through the user interface. 4.4.5. Configuration items are stored, managed, and controlled within a Configuration

Management Data Base (CMDB). 4.4.5.1. CIs are always associated with a classification type. 4.4.5.2. Actual CIs are stored in the Configuration Management Data Base (CMDB) in

accordance with the Common Data Model (CDM). 4.4.5.3. For each resource type, IBM Control Desk’s Common Data Model defines

standard classifications that determine: Allowable attributes and types; Valid relationships to other actual Cis; and Naming rules.

4.4.5.4. The CDM classifications, attributes, and relationships are preinstalled in IBM Control Desk, or loaded from IBM’s discovery and relationship mapping tool - Tivoli Application Dependency Discovery Manager via IBM Tivoli Integration Composer (ITIC).

4.4.6. Authorized CIs are stored according to your custom CI classification hierarchy (custom classifications hierarchy; promotion scopes that include mappings between authorized classifications and actual classifications; relationships between authorized classifications; and attributes for each resource type). Custom CI classification hierarchies are created and maintained in Deployer’s Workbench.

4.4.7. In the Configuration Items application, you can access and view all the details for an authorized CI. 4.4.7.1. The CI Summary tab contains information that has been gathered from the

attributes and metadata of the CI. 4.4.7.2. The CI Details tab shows all the attributes for the CI. 4.4.7.3. The Related Configuration Items tab shows the relationships in which the

current CI is a part. 4.4.7.4. CI Details for an authorized CI when linked to an actual CI, illustrate any

discrepancies between the actual and the authorized CI. 4.4.8. The CMDB stores and maintains relationships between CIs.

4.4.8.1. Configuration items are connected through uni-directional relationships. 4.4.8.2. Related Configuration Items record and show you all the relationships in which

the current CI is either the parent of the child. 4.4.9. Configuration Management Reconciliation Tasks provide the mechanics to automate

the linkage between authorized CIs and actual CIs, between assets and deployed assets, and between authorized CIs and assets. These links provide the basics for the CI Audit function.

4.4.10. Configuration Items (CIs) are created in the CMDB in a number of different ways. 4.4.10.1. Actual CIs are created automatically when information from your discovery

tool is loaded into the CMDB (e.g., through ITIC). If you do not use a

discovery tool, actual CIs may be added by importing comma-separated or xml files. However, this is not the recommended path since the actual CI information reflects the current configuration of your data center, so by nature this information is updated frequently. To capture the changes to your infrastructure, you should use a discovery tool that can capture all the details and relationships, on a recurring scheduled basis.

4.4.10.2. Authorized CIs may be created manually, to represent a resource that does not yet exist; By promoting top-level actual CIs, to represent an existing resource; By synchronizing an existing top-level CI, and include descendant Cis; and Automatically from assets, to represent a computer system.

4.4.11. Authorized CIs are most commonly created by Promoting actual CIs. Only actual CIs for which one or more promotion scopes have been defined for the classification can be promoted. 4.4.11.1. Promotion creates or updates authorized CIs by cloning actual top-level CIs. 4.4.11.2. Promotion scopes are used to identify all related CIs that are included, and

map them to authorized classifications. 4.4.12. Authorized CIs can only be deleted from the CMDB if the current status of the CI, also

known as the lifecycle state, is not protected; the CI is not included in a baseline; the CI is not, and has never been, related to a process request or ticket; or the CI is not, and has never been, the target of a change or configuration work order.

4.4.13. A configuration baseline is a snapshot that represents an Authorized (approved) Configuration at a particular point in time. The baseline documents the configuration of the application system (CIs, attributes, and relationships) as it existed when you created the baseline. 4.4.13.1. Multiple CIs can be members of a baseline. 4.4.13.2. Baselines can at any point be compared to the current configuration of the

actual CIs that are linked to the members of the baseline. 4.4.13.3. Using baselines, you can quickly detect changes to your approved

configurations. The changes that you can detect are additions and deletions of CIs as well as modifications to CI attributes and relationships.

4.4.14. CI Lifecycles are used to associate information about the operational state of an Authorized CI. The state provides information about how the resource is used. 4.4.14.1. A lifecycle defines a set of states and authorized transitions that occur

between them. 4.4.14.2. Every lifecycle must have one state that is designated as the default state,

and states can be defined as protected. 4.4.14.3. Transitions involving protected states must be associated with a change

request. 4.4.14.4. Each CI classification can be assigned one lifecycle. 4.4.14.5. IBM Control Desk supports the use of multiple lifecycles and customizable

lifecycles. 4.4.14.6. Reconciliation Tasks provide the mechanism that is used to perform the CI

Audit, which is important to ensure that the CMDB can be trusted. The basic functions that are used to link and compare actual and authorized resources in IBM Control Desk is that of the Reconciliation Task. Reconciliation Tasks provide the mechanics to automate the linkage between authorized CIs and actual CIs, between assets and deployed assets, and between authorized CIs and assets.

4.4.15. Change management is the process that is responsible for protecting the production environment. IBM Control Desk’s standardized methods and processes are defined for efficient and prompt handling of all changes. The purpose is to minimize or avoid the impact of change-related incidents on service quality and availability.

4.4.16. The activities that are performed by Change Management are typically triggered by Change Requests – or Request For Change - RFC. Change requests are generated and submitted by requestors, or automatically as the result of a service request. 4.4.16.1. The Change Request is used to: Document, justify, and apply approval

gates – or workflow for the request; identify and document the requestor; and assign cost center Requestor.

4.4.16.2. Change Requests contain key information about the change, including a description of the change, and a classification. The classification is used to specify the type of change that is requested.

4.4.16.3. Change requests are assigned to, reviewed by, and accepted (or rejected) by the change owner, or the change manager, who can also assign ownership of the change to a change owner, or a group of change owners.

4.4.16.4. The initial step in change processing is to properly categorize it. Categorizing the change considers and documents the following attributes, so that it may be reviewed and approved/rejected: Target CI(s); Urgency; Probability of Failure; Impact; (Once values are provided for urgency and probability of failure, IBM Control Desk calculates values for Impact and replaces the original value if the calculated impact is more severe than the value originally applied); Priority; Risk; and the specific change type (standard, normal, emergency).

4.4.16.5. During processing, a change request passes through several phases. Each phase of the Change Process is responsible for performing specific activities to specify, analyze, access, schedule, approve, implement, review, and close the change.

4.4.16.6. Work on the target CI(s) is performed only during the implementation phase. The actual work is defined by the activities and tasks that are involved are specified in a job plan.

4.4.17. Within IBM Control Desk, response plans are developed to such level of detail, that the work for the change owner is reduced to verifying that the change specification is valid. Response plans can be assigned based on detailed specifications, for example using the combination of change classification, urgency, classification of the target, site, and requester group. This means, that specific response plans can be created in order to automate the processing, or minimize the work that is required by the change owner.

4.4.18. Changes are specified by creating a Job Plan for the change. Job plans include tasks that must be completed in order to implement the change. Some tasks may be associated with target CIs, others may not. Implementation tasks are used to indicate whether the specified target CIs will be subject to an outage during the task. All tasks must have owners, who are responsible for performing the task. Tasks must have a duration. In the job plan, the flow of tasks is controlled by assigning predecessors to any task.

4.4.19. When the last task of the change is completed, the status of the change is set to Completed and the requester receives a message to review and close the change.

4.4.20. Change assessment consists of three activities: Impact analysis; Technical assessment; and Business assessment. Impacts are calculated automatically by the

workflow that governs the process. Impacts are identified only for implementation tasks. The impact analysis is based on CI relationships. 4.4.20.1. Within IBM Control Desk, Impact Analysis is performed automatically by the

change process workflow. It can be recalculated at any time, to reflect modifications to the change.

4.4.20.2. The need for impact assessments is determined by the Change Owner during the specification of the change.

4.4.20.3. Technical assessments are performed by Change Analysts 4.4.20.4. Business assessments are performed by Business Analysts.

4.4.21. Change Scheduling focuses on finding appropriate time slots in which to perform implementation tasks. 4.4.21.1. The following factors are taken into account when scheduling a change: CI

outage (none, degraded, or offline) for both target and impacted CIs; CI change windows for both target and impacted CIs; Blackout periods; Resource availability (if you are using calendars for the task owners); and Task dependencies.

4.4.21.2. IBM Control Desk’s Change Scheduler provides an interactive Gantt chart in which you can visualize and modify the planned schedule, alongside and in consideration of resource availability and constraints.

4.4.22. When the change has been categorized, assessed, and scheduled it is ready to be Authorized. 4.4.22.1. IBM Control Desk automatically assigns approval tasks to the change

approvers that are specified in the change. 4.4.22.2. Authorization can be granted from individual approvers, or members of an

approval group (the Change Advisory Board - CAB). In addition, you can specify several levels of approval, and prioritize them.

4.4.22.3. If multiple approvers are specified, you can configure the approval workflows to receive approval in multiple ways – ranging from ‘one member from one group at any level’ to ‘all members of all groups at all levels’. The approval workflows will automatically assign approval task, as needed.

4.4.23. Release Management is the controlled deployment of approved changes within the IT infrastructure. It is fully integrated with change management. It is used to manage complex changes to both hardware and software resources. Releases are used to deploy major update bundles of changes to the infrastructure on a routine and or scheduled basis. 4.4.23.1. In IBM Control Desk, the release management process is driven by standard

job plans and task automation that is used by Tivoli's Process Automation Engine (TPAE), rather than workflows.

4.4.23.2. Approved changes can be imported into a change to reference CIs. (There is no linkage in the implementation phase).

4.4.23.3. The first phase of a release is the Plan phase. In this phase, the release owner defines the major milestones and outlines the high-level activities of for the release. To complete this task, the release owner used standard Tivoli Process Automation Engine facilities to create a job plan that contains activities and tasks which might or might not depend on one another. IBM Control Desk provides sample job plans that may be used as-is or modified and used (and saved for reuse).

4.4.23.4. When defining the release plan, the release owner can use special task classifications to apply special processing for selected tasks. IBM Control Desk provides a set of pre-defined task classifications.

4.4.23.5. Design and Build is the responsibility of the release specialist, and consists of developing and documenting the necessary procedures, scripts, and definitions in the tools that are used for deployment, needed to deploy the software or components in scope.

4.4.23.6. Testing and Verifying the release package is the responsibility of the release deployer, who tests the release package, and documents the results. Upon successful testing (acceptance), the software package is registered in the definitive media library.

4.4.23.7. When all the procedures for deployment and implementation of the changes in the release have been defined and approved, the release owner creates a release plan – or planned rollout. Typical activities for this phase are to: Create detailed plans with dates and deliverables for the rollout to each site; Schedule delivery of any new (HW) CIs to each site; Schedule the release implementation; and Schedule training.

4.4.23.8. During the Scheduling phase, IBM Control Desk’s Scheduler application allows the creation of a release implementation schedule using a graphical interface that shows the schedule alongside the resource utilization, change windows, and blackout periods. This helps ensure that you schedule the implementation tasks at the optimal times.

4.4.23.9. During the Release Synchronization and Communication phase, the release implementation schedule is communicated to stakeholders, users, and support personnel about the upcoming events, and schedules site-specific testing, system shutdowns, including reminders about the release.

4.4.23.10. During the implementation of the release, the following activities are scheduled and occur as part of the implementation plan: Distribution and installation of hardware and software, ensuring appropriate data is provided for asset and configuration updates; initiate updates that use the Identity and Access Management process and security management process; removal of redundant services and assets, (processes, procedures, and tools); and introduction of new or changed processes – procedures – and work instructions to the service delivery teams responsible for service management activities.

4.4.23.11. The Release Review phase, documents and assesses the effectiveness of the release, which provides valuable input for the next release in terms of what worked and what did not, what to do and what not to do, and revisions in the schedule about timing and scheduling of resources – tasks – and activities.

4.5. Perform troubleshooting and problem determination on IBM Control Desk. SUBTASK(S): 4.5.1. Debugging and Trouble Shooting a Install/Upgrade Error

4.5.1.1. Debugging a Install issues could require any of these skills to do problem determination. 4.5.1.1.1. Network – Can multiple hosts talk to each other on specific ports,

debug personal firewall or network firewall, etc

4.5.1.1.2. Hardware – How to install/configure and debug machines, network devices, etc

4.5.1.1.3. Operating System – install and configure required libraries, configure and debug networking, exporting Display, etc

4.5.1.1.4. Database - How to run and debug database commands 4.5.1.1.5. Application Server - Understand how WebSphere interacts

internally: Cell->node->JVM. How to debug configuration issues. 4.5.1.2. Location of Install log file to get additional information

4.5.1.2.1. Installer verification UI panels - <Install User Home dir> 4.5.1.2.2. ICD General Installation error - <root>\IBM\SMP\logs 4.5.1.2.3. ICD Database Installer errors -

<root>\IBM\SMP\maximo\tools\maximo\log 4.5.1.3. Review installation document. 4.5.1.4. Search the IBM Support page for the error. 4.5.1.5. Search the World Wide Web for a previously report error. 4.5.1.6. Contact IBM Support.

4.5.2. Debugging and Troubleshooting a ICD Runtime Error 4.5.2.1. Debugging a Install issues could require any of these skills to do problem

determination. 4.5.2.1.1. Database - How to run and debug database commands 4.5.2.1.2. Application Server - How to debug and configure WebSphere 4.5.2.1.3. Control Desk - How to increase logging and add new

logs/statements 4.5.2.2. Location of ICD log file to get additional information

4.5.2.2.1. WebSphere application and Network Manager - \IBM\WebSphere\AppServer\profiles\<profilename>\logs\<JVM instance name>

4.5.2.2.2. WebSphere Maximo logs - \IBM\WebSphere\AppServer\profiles\<profilename>\maximo\logs

4.5.2.3. Manage the Logging application settings. 4.5.2.3.1. Identify and define the logging application.You can modify and

create log files that contain informational, warning, or error messages about the system.

4.5.2.3.2. Identify Log Levels

ERROR – Logs messages indicating errors in the application functionality

DEBUG – Logs messages that are useful in debugging

FATAL – Logs very severe errors messages

INFO – Logs informational messages

WARN – Logs messages indicating harmful situations in functionality

4.5.2.4. Common Tasks that need debugging - Each of these require a different skill set to debug them 4.5.2.4.1. Application Designer 4.5.2.4.2. Database Configuration 4.5.2.4.3. WorkFlow 4.5.2.4.4. Esacalation 4.5.2.4.5. CronTasks

4.5.2.4.6. Automation Scripting 4.5.2.4.7. Actions, etc

4.5.2.5. Search the IBM Support page for the error. 4.5.2.6. Search the World Wide Web for a previously report error. 4.5.2.7. Contact IBM Support.

4.6. Create ad-hoc reports and run system reports. SUBTASK(S): 4.6.1. Running reports

4.6.1.1. Many ICD applications support a “Run Reports” action. There is also a “Reports” menu in the ICD 7.6 banner that can be used to find the reports that have been enabled for different applications. The “Run Reports” action and the “Reports” menu are used to trigger or schedule the execution of BIRT reports.

4.6.1.2. To have access to the “Run Reports” action for a particular application, the user must be a member of a Security Group that grants authorization for that action in the application.

4.6.1.3. Invoking the “Run Reports” action (or selecting a report from the “Reports” menu in the ICD banner), causes a “Reports” panel to be displayed. When the user clicks a specific report link in the panel, the request page for the report is displayed. The request page may include some “Help Text” and some input “Parameters” that can be specified before the report is run. The “Reports” panel also provides the ability for the user to schedule the report for execution at different times and the ability to indicate that the report results should be e-mailed to different people.

4.6.2. Ad Hoc Reports 4.6.2.1. ICD 7.6 support a “Query Based Reports” facility. “Query Based Reports” are

very simple to generate and they can be saved for repeated use. The reports can run against the list of records that are displayed in the “List” tab page of an application or they can be defined to run against a specific application query that is stored within the ad hoc report.

4.6.2.2. Applications that support the running of reports also support a “Create Report” action. Access to the “Create Report” action is controlled by a separate Security Group authorization for the application. The “Reports” panel (triggered by the “Run Reports” action) also includes a “Create Report” button.

4.6.2.3. Triggering the “Create Report” action brings up a “Query Based Report” panel. There are four tabbed pages within the panel: 4.6.2.3.1. “Style”- “Summary” reports produce simple list of records. “Detail”

reports can display both a primary list of records and also details about other records that the primary records point to (e.g. the Work Log records that an Incident record points to).

In order to display fields from associated records, the Reporting Object Structure for the primary object (i.e. the primary table for the current application) must specify a linkage to that other table.

The “Style” page also permits the user to title the new report, indicate whether the report is available for public use and whether the report should be saved. Saved reports appear in the “Report” panel and in the “Reports” menu within the ICD

banner. 4.6.2.3.2. “Select”- On this page the user selects which attributes to display

within the ad hoc report. For “Summary” reports, all these attributes are within the primary object. For “Detail” reports, the user will be able to select from attributes in tables that are exposed via the Reporting Object Stricture.

The user can control the order of the columns that will display the selected attributes.

The user also has the choice of indicating that the ad hoc report runs against the current application query or the current query (at the time this reported is submitted and saved) should be saved within the ad hoc report and that query will be performed each this report is subsequently run.

4.6.2.3.3. “Format”- While Query Based Reports are simple to configure, this page does offer the user some control over the grouping and sorting of the records that will be displayed. The user can also specify that people who run the ad hoc report will see some filtering parameters in the request page for the report.

4.6.2.3.4. “Submit”- This page provides the same report submission options as are included in the “Reports” panel that is used to run a report.

4.6.2.4. Modifying an Ad Hoc Report 4.6.2.4.1. The creation of an Ad Hoc Report generates a report in BIRT format.

Existing Ad Hoc Reports can be edited using the same ICD panels that are sued to create the reports. It is also possible to export the generated BIRT format to the BIRT development environment; where it can be extended beyond the capabilities of ICD Ad Hoc Report panels.

4.6.2.5. Deleting Ad Hoc Reports 4.6.2.5.1. If the user is authorized for the “Delete Report” action (for a specific

application), then the user can delete ad hoc reports that are no longer required.

4.6.3. Cognos Reports 4.6.3.1. ICD 7.6 adds support for a new set of Cognos reports. These reports can be

run as-is. It is also possible to modify the reports. 4.6.3.2. The Report Administration application provides access to the Cognos

environment. Cognos reports can be run or modified from within that environment.

Next Steps

1. Take the IBM Control Desk v7.6 Fundamentals assessment test using the promotion code AAASYSMIDBP for $10 ($20 USD savings).

2. If you pass the assessment exam, visit pearsonvue.com/ibm to schedule your testing sessions. Use the promotion code sysmidguide to receive 20% off.

3. If you failed the assessment exam, review how you did by section. Focus attention on

the sections where you need improvement. Keep in mind that you can take the assessment exam as many times as you would like ($10 per exam), however, you will still receive the same questions only in a different order.