Symantec SERVICEDESK 7.0 - CUSTOMIZATION GUIDE User manual

SYMANTEC®
ServiceDesk
Customization Guide
7.0

Symantec® ServiceDesk Customization Guide 7.0 2
Symantec ServiceDesk 7
The software described in this book is furnished under a license agreement and may be used only in accordance with the terms of the
agreement.
Documentation version 4, revised 28 October 2010
Legal Notice
Copyright © 2010 Symantec Corporation. All rights reserved.
Symantec, the Symantec Logo, and Altiris are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and
other countries. Other names may be trademarks of their respective owners.
The product described in this document is distributed under licenses restricting its use, copying, distribution, and decompilation/reverse
engineering. No part of this document may be reproduced in any form by any means without prior written authorization of Symantec
Corporation and its licensors, if any.
THE DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE
DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. SYMANTEC CORPORATION SHALL
NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS
DOCUMENTATION. THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS SUBJECT TO CHANGE WITHOUT NOTICE.
The Licensed Software and Documentation are deemed to be commercial computer software as defined in FAR 12.212 and subject to
restricted rights as defined in FAR Section 52.227-19 "Commercial Computer Software - Restricted Rights" and DFARS 227.7202, "Rights in
Commercial Computer Software or Commercial Computer Software Documentation", as applicable, and any successor regulations. Any use,
modification, reproduction release, performance, display or disclosure of the Licensed Software and Documentation by the U.S. Government
shall be solely in accordance with the terms of this Agreement.
Symantec Corporation
350 Ellis Street
Mountain View, CA 94043
http://www.symantec.com

Symantec® ServiceDesk Customization Guide 7.0 3
Technical Support
Symantec Technical Support maintains support centers globally. Technical Support’s
primary role is to respond to specific queries about product features and functionality.
The Technical Support group also creates content for our online Knowledge Base. The
Technical Support group works collaboratively with the other functional areas within
Symantec to answer your questions in a timely fashion. For example, the Technical
Support group works with Product Engineering and Symantec Security Response to
provide alerting services and virus definition updates.
Symantec’s maintenance offerings include the following:
zA range of support options that give you the flexibility to select the right amount of
service for any size organization
zTelephone and Web-based support that provides rapid response and up-to-the-
minute information
zUpgrade assurance that delivers automatic software upgrade protection
zAdvanced features, including Account Management Services
For information about Symantec’s Maintenance Programs, you can visit our Web site at
the following URL:
www.symantec.com/techsupp/
Contacting Technical Support
Customers with a current maintenance agreement may access Technical Support
information at the following URL:
www.symantec.com/techsupp/
Before contacting Technical Support, make sure you have satisfied the system
requirements that are listed in your product documentation. Also, you should be at the
computer on which the problem occurred, in case it is necessary to replicate the
problem.
When you contact Technical Support, please have the following information available:
zProduct release level
zHardware information
zAvailable memory, disk space, and NIC information
zOperating system
zVersion and patch level
zNetwork topology
zRouter, gateway, and IP address information
zProblem description:
Error messages and log files
Troubleshooting that was performed before contacting Symantec
Recent software configuration changes and network changes

Symantec® ServiceDesk Customization Guide 7.0 4
Licensing and registration
If your Symantec product requires registration or a license key, access our technical
support Web page at the following URL:
www.symantec.com/techsupp/
Customer service
Customer service information is available at the following URL:
www.symantec.com/techsupp/
Customer Service is available to assist with the following types of issues:
zQuestions regarding product licensing or serialization
zProduct registration updates, such as address or name changes
zGeneral product information (features, language availability, local dealers)
zLatest information about product updates and upgrades
zInformation about upgrade assurance and maintenance contracts
zInformation about the Symantec Buying Programs
zAdvice about Symantec’s technical support options
zNontechnical presales questions
zIssues that are related to CD-ROMs or manuals
Maintenance agreement resources
If you want to contact Symantec regarding an existing maintenance agreement, please
contact the maintenance agreement administration team for your region as follows:
Additional enterprise services
Symantec offers a comprehensive set of services that allow you to maximize your
investment in Symantec products and to develop your knowledge, expertise, and global
insight, which enable you to manage your business risks proactively.
Enterprise services that are available include the following:
Asia-Pacific and Japan [email protected]
Europe, Middle-East, and Africa [email protected]
North America and Latin America [email protected]
Symantec Early
Warning Solutions These solutions provide early warning of cyber attacks, comprehensive threat analysis, and countermeasures to prevent
attacks before they occur.
Managed Security
Services These services remove the burden of managing and monitoring security devices and events, ensuring rapid response to real
threats.

Symantec® ServiceDesk Customization Guide 7.0 5
To access more information about Enterprise services, please visit our Web site at the
following URL:
www.symantec.com
Select your country or language from the site index.
Consulting
Services Symantec Consulting Services provide on-site technical expertise from Symantec and its trusted partners. Symantec
Consulting Services offer a variety of prepackaged and
customizable options that include assessment, design,
implementation, monitoring, and management capabilities. Each
is focused on establishing and maintaining the integrity and
availability of your IT resources.
Educational
Services Educational Services provide a full array of technical training, security education, security certification, and awareness
communication programs.

Symantec® ServiceDesk Customization Guide 7.0 6
Contents
Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
ServiceDesk 7 High-Level Capabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Relationship Between ServiceDesk 7 & Symantec Workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Process Manager (ServiceDesk) Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Relationship Between ServiceDesk 7 & Altiris Notification Server (NS) Computer . . . . . . . . . . . . . . . 9
Best Practice: Keep It Simple in the Beginning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Phases in Implementing ServiceDesk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Phase 1: Process and Workflow Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Step 1: Select Pieces of ServiceDesk 7 to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Step 2: Identify Current Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Phase 2: Installation, Configuration, and Basic Customization . . . . . . . . . . . . . . . . . . . 13
Installation & Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Notification Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
ServiceDesk 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Versioning Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Pros and Cons of Writing to the Same Virtual Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Development Considerations When Publishing to the Same Virtual Directory . . . . . . . . . . . . . . 16
Basic Steps for Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
About Application Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Restoring ServiceDesk Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Project Differential Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Basic ServiceDesk 7 Customization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Editing the Core ITIL Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Verify Users, Groups, and Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Set Up Incident Categories (Classifications). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Verify Default Priority, Impact, and Urgency Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Verify Close Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Portal Master Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Customize the General Appearance of the Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Customize Form Appearance & Content. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Establish Routing (Assignment) of Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Establish Service Level Agreement (SLA) Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Set Business Hours & Holidays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Set Up “Follow the Sun” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Change the Frequency of the Customer Service Satisfaction Survey. . . . . . . . . . . . . . . . . . . . 37
Define Quick Incident Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Define E-mail Content. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Customize E-mail Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Modify the Timespan for End-Users to Confirm Incident Resolution. . . . . . . . . . . . . . . . . . . . . 42
Establish Change Management Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Change Risk Assessment Participation for Change Management. . . . . . . . . . . . . . . . . . . . . . . 42
Verify Problem Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Symantec® ServiceDesk Customization Guide 7.0 7
Phase 3: Advanced Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Extend Data/Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
About SD.Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Extend the ServiceDesk Incident Data Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Extend the CustomerServiceSurvey Data Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Extend the Change Request Data Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Extend the ServiceDesk Problem Data Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Add & Customize Pages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Modify Types of Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Define Smart Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Add Smart Tasks to the Initial Diagnosis Dialog Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Add to the Service Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Define New Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Creating a Child Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Configure Automatic Generation of Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Making a Report a Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Replicating ServiceDesk Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Create a New Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Adding & Removing E-mail Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Application Property for Two Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Remove an Approval Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Customize the Spell Checking Dictionary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Create Incidents from Other Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Notification Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Other Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Integrate ServiceDesk 7 with Other Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Create a Web Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Non-Changeable Items in Symantec Workflow Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
ServiceDesk 7 scalability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Example topology of a ServiceDesk 7 cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Setting up ServiceDesk 7 cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Additional information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Symantec® ServiceDesk Customization Guide 7.0 8
Introduction
With Symantec® ServiceDesk 7 software, you can provide the level of service that your
organization expects and can afford, keeping hundreds—even tens of thousands—of
computers running efficiently, while providing new services on a regular basis.
The key is to create an organized environment that quickly responds to reported issues,
and, at the same time, advertises and provides new services to the organization. The
ultimate goal is to provide better service by automating as many steps as possible, and,
where automation isn't possible, to increase the efficiency of the people who provide the
services.
Intended Audience
This guide (particularly sections 2 and 3), is for administrative users who plan to
customize ServiceDesk 7 on their own. You can also leverage experienced consultants to
help.
Note:
It is required that you have working knowledge of Symantec Workflow in order to
perform many of the configuration steps explained in this document.
ServiceDesk 7 High-Level Capabilities
ServiceDesk 7 can be configured to capture issues electronically through e-mail or from
other applications, or through special Web-based screens designed for end-users or
technicians to log an incident. End-users receive updates on all problems that they
report. Once an issue is reported, it can be prioritized and routed to the right people who
can solve the problem and report the success back to the users and management.
ServiceDesk 7 has many automated capabilities that can drive down the amount of
human effort needed to correct issues. In other cases, where several people need to be
involved in the process, such as purchasing, installing, and provisioning a new server,
ServiceDesk 7 can provide coordination between all of the parties to help eliminate
delays and improve service levels. ServiceDesk 7 can then become a central
communication and coordination center for all of the things going on in the IT
department, and in many cases it can extend beyond IT to provide services to Facilities,
Telecommunications, Human Resources, Equipment Maintenance, and so on.
An IT process is a predefined series of steps that are executed in a repeatable way to
deliver the same expected outcome each time the process is triggered. When a company
can move from a place where IT problems are solved in an ad-hoc manner to one where
every issue is handled in an efficient and repeatable manner, cost goes down and end
user satisfaction goes up.
A workflow is the implementation of an IT process in ServiceDesk 7. Workflows are
housed in projects, built in the Symantec Workflow software.

Symantec® ServiceDesk Customization Guide 7.0 9
Relationship Between ServiceDesk 7 & Symantec
Workflow
ServiceDesk 7 relies upon Symantec Workflow software to drive the core ServiceDesk 7
ITIL processes, and the Service Catalog and Knowledge Base process. Symantec
Workflow is a critical technology to understand, as it is fundamental to the functionality
and customization of ServiceDesk 7. Most customization explained in this document is
done using this tool.
ServiceDesk 7 processes are contained in Symantec Workflow projects that are provided
by the ServiceDesk 7 installation.
ServiceDesk 7 follows a different paradigm than other helpdesk applications in that it is
driven by process, not by data. The process enforces the rules. Symantec took great
care in creating the processes, taking into account customer feedback and ITIL best
practice recommendations.
Note that changes to a Symantec Workflow project require testing and deployment to
production in order for the changes to become visible to ServiceDesk 7 users. The
instructions in this document cover the basics of deployment, but more in-depth
instructions on it and using the Debugger for testing are covered in the Symantec
Workflow documentation.
Process Manager (ServiceDesk) Database
The term “Process Manager” refers to the database that stores process data, and
ServiceDesk data such as groups, users, and permissions. The Process Manager
database is a standard part of Symantec Workflow; when you install ServiceDesk, it is
expanded to become the ServiceDesk database (however it is commonly referred to as
“Process Manager”). This database resides on the SQL Server computer.
Relationship Between ServiceDesk 7 & Altiris
Notification Server (NS) Computer
Note:
Symantec Management Platform 7.0 is the product installed on the NS computer that
manages the licensing.
Previous versions of Altiris HelpDesk used the Notification Server computer to define
business rules; now all of these are handled in Symantec Workflow. ServiceDesk 7 relies
upon Altiris Notification Server for three functions:
zLicensing information,
zIT asset locations, configurations, and historical information, and,
zExposure to the Configuration Management Database (CMDB).
It is required to have Notification Server computer up and running, and configured, prior
to implementing ServiceDesk 7.

Symantec® ServiceDesk Customization Guide 7.0 10
Best Practice: Keep It Simple in the Beginning
Out-of-the-box, ServiceDesk is intended to require little customization; use this guide as
a checklist to identify the most important aspects to customize.
Keep the initial implementation of ServiceDesk 7 simple enough for most of your staff to
understand and manage. Aim to provide the basic functionality and services needed to
achieve a reasonable amount of satisfaction, not the ultimate “end all” solution. Then,
build up the ServiceDesk 7 system over time as the support staff and the end-users
become more familiar with it.
Phases in Implementing ServiceDesk
This document organizes the process of implementing ServiceDesk 7 into 3 phases.
zPhase 1: Process and Workflow Planning (page 11)
zPhase 2: Installation, Configuration, and Basic Customization (page 13)
zPhase 3: Advanced Customization (page 46)

Symantec® ServiceDesk Customization Guide 7.0 11
Phase 1: Process and Workflow Planning
In this initial phase, you consider the processes that you want to use in ServiceDesk 7.
There are the four core ITIL processes (Incident Management, Change Management,
Problem Management, and Release Management), a Service Catalog, and Knowledge
Base process; you may or may not want to use all of these.
You also want to map out your current process so you can identify where customizations
need to be made in the “out of the box” ServiceDesk 7 processes.
Step 1: Select Pieces of ServiceDesk 7 to Use
The following explanations will help you determine what processes you want to use in
ServiceDesk 7. Most clients will use Incident Management at a minimum. These
processes directly follow Symantec’s opinion of ITIL best practices, determined through
customer feedback and scrutiny of ITIL documentation.
zIncident Management Process
The incident management process manages incidents with a focus on restoring the
user to an operational state as quickly as possible to the level identified in the
Service Level Agreement.
zProblem Management Process
The problem management process aims to reduce the occurrence and negative
impact of incidents that are reported to the ServiceDesk. The process looks
proactively for trends in the environment to identify the root cause of incidents and
initiates action to improve or correct the situation.
zChange Management Process
The change management process aims to plan for and control the risks and impacts
of changes to the IT infrastructure. Changes are handled according to standardized
procedures to minimize impact on service.
zRelease Management Process

Symantec® ServiceDesk Customization Guide 7.0 12
The release management process aims to distribute and maintain tested versions of
software and licenses for the software. It provides oversight of all other changes
and releases to identify any problems or conflicts.
zKnowledge Base Process
The knowledge base process provides a centralized location for information used in
diagnosing and resolving incidents.
zService Catalog
The Service Catalog provides links to routine “self-service” functions. Examples
include automated password reset, and automated software request.
Step 2: Identify Current Processes
Think about how your organization currently addresses incidents, both formal and
informal processes, how incidents are reported, who is the first to find out about them,
what happens next, and so on.
Plot the current processes in flow charts, nothing where you would like to see changes.
These flowcharts will help guide you when you go into Symantec Workflow to do
customization.
Consider these questions when thinking about your current processes:
zIs the process different if the issue is a hardware problem or a software problem?
zIs the process different if you don't know what is causing the issue, only that a user
is unhappy?
zHow do you determine if an issue is a high priority or what the level of impact to the
organization is? This part of the ServiceDesk 7 system is managed by Priority,
Urgency, and Impact fields.
zWhen the root cause is identified, what tools does your team use to troubleshoot
and remedy the situation?
zDo you handle incidents differently than problems (based on the ITIL definitions of
incidents and problems)? If so, what is the process from start to finish for the Level
2 workers to follow?
zHow are service requests handled? For example, if an employee needs to move from
one office to another, who in your organization is involved with that and what are
the process steps?
zWhat would you like end-users to be able to do themselves?
Consult your IT staff to determine what part different employees will take in workflows,
and how your staff’s areas of expertise may influence your ServiceDesk 7
implementation.

Symantec® ServiceDesk Customization Guide 7.0 13
Phase 2: Installation, Configuration, and Basic
Customization
Installation & Configuration
Notification Server
Before you install ServiceDesk 7, you must install Notification Server and complete at
least an initial discovery and inventory. For details, see the Notification Server online
help.
ServiceDesk 7
The ServiceDesk 7 installation installs both ServiceDesk and Symantec Workflow
Solution.
The ServiceDesk 7 Installation Guide covers all the necessary installation steps and
configuration. Configuration includes several important steps, such as determining
where users/groups/organizations and permissions come from (typically Active
Directory), setting the location of databases, and migrating existing Help Desk 6.5
content.
Migrate Incidents
Migration of incidents can happen during installation or afterwards, from the Service
Catalog. Best practice is to migrate all incidents from Help Desk 6.5. Incidents from Help
Desk 6.5 are not truly “migrated,” rather meta data is brought in; technicians will see
the incidents but actually work them in Help Desk 6.5 via an IFrame. Therefore it is
necessary to keep Help Desk 6.5 up and running until all of its tickets are closed. Best
practice is to cut off users from submitting new incidents into Help Desk 6.5 once
incident migration occurs. Since migrated incidents receive their own category in
ServiceDesk and are prefixed with “SDM-,” you can run a report or sort the list of all
incidents to see if the count is down to zero, meaning it is time to take down Help Desk
6.5.
Closed Help Desk 6.5 incidents are automatically imported into the ServiceDesk 7
database for reporting purposes. In fact, you’ll notice that closed tickets are not
available for migration, since they are already handled behind the scenes. Closed tickets
are imported upon the migration, and as tickets are closed post-migration, a
ServiceDesk process automatically checks for them once a day and imports those that
are found.
Migrate Categories
Migration of categories can happen during installation or afterwards, from the Service
Catalog. If you are going to use categories from Help Desk 6.5, best practice is to import
them before new incidents are created in ServiceDesk.

Symantec® ServiceDesk Customization Guide 7.0 14
Migrate Knowledge Base (KB) Content
Migration of KB content is performed by running a KB Migrator executable found in the
Service Catalog. Out of the box, the migrator is configured to migrate Help Desk 6.5
HTML files, however the process can be modified to import content from another
document repository. The project that performs the migration is SD.KBMigrationProcess.
Prerequisites:
zBefore you run the KB Migrator, you must copy the directory that houses the KB
files to the ServiceDesk server. This is required due to .NET restrictions at the
command-line level.
zThe directory structure for the KB content to copy must follow this format:
C:\Libraries\another directory\Articles. This is the directory structure of HelpDesk
6.5 Knowledge Base content by default. The “another directory” folder represents
the individual libraries.
zYou must also grant the Network Service account access to the directory
After migration, you can delete the copied directory (unless there were failures and you
want to run the migrator again for the .failed content).You can run the migration tool
multiple times, however do not run the migrator against content that is already
migrated. This is due to high risk of duplication of articles.
Be advised that the migration process takes a long time to complete (testing against the
average-sized KB of a few thousand entries took approximately 8 hours). You can check
the Configuration Logging Utility for Symantec Workflow to make sure it is still running.
(In the tool, right-click the KB migration process, turn on logging, and go to the Log
View tab.)
The migration wizard sends notifications throughout the migration process to the e-mail
address specified in one of the wizard screens. You are notified each time a KB category
successfully migrates, and if there’s a failure (down to the specific article that failed).
If a directory fails migration multiple times, you should remove the articles from the
source directory, delete the source directory, then try to migrate smaller subsets of
those articles to help identify a problematic article. There is a “visual” setting you should
turn on in the migration wizard that will provide more detail. The process tries 3 times
before it deems a true failure.
Note that the numbering of the migrated articles is new, and is based on the order of
import. You could retain your old numbering, however that would also require modifying
SD.KBMigrationProcess to get the current number of the article.
After migration is complete, the original source directory can be deleted. Migrated KB
articles are stored to the Process Manager database (however images used in articles
are saved to the server drive).
Versioning Processes
Before making changes to the Symantec Workflow processes that ship with
ServiceDesk, it is important to determine a versioning process. Versioning enables you
to return to a prior working state if necessary, and to track the origin of a change.
By default, each time you click Save in Symantec Workflow, a copy of the project is
automatically stored in the C:\Program Files\Altiris\Workflow
Designer\WorkflowProjects\Backup directory. Up to ten copies are saved.

Symantec® ServiceDesk Customization Guide 7.0 15
The versioning method in this section is a very simple versioning method. Its steps
include:
1. Create a copy of a project, renaming the copy accordingly
2. Make and test changes
3. Publish to production
Use the name of the project (renamed in step 1)
Rename the virtual directory (optional)
4. Update the application property in ServiceDesk (optional)
A more sophisticated change management process is detailed in a series of 4 videos
posted to http://www.WorkflowSwat.com, under “Learn.” This way of maintaining
versions of processes is recommended for companies that have larger scale usage of
Workflow processes. Symantec recommends reviewing both methods then making a
decision that makes sense for your organization.
Pros and Cons of Writing to the Same Virtual Directory
If a process is going to a new virtual directory, you are essentially creating a completely
new process (even if the process does the exact same thing as the old process). All of
the “in progress” tickets continue to use the original process. ServiceDesk starts to use
version 2 of that process for all new instances initiated after publishing AND after
updating the application property in ServiceDesk with the new location of the process.
Publishing to the same virtual directory (essentially overwriting an existing process), can
break current instances of the process. However, “breaking” is very unlikely for “quick”
processes, such as routing rules that only run for a split second.
If you publish over an existing virtual directory the only instances that are broken are
ones in an active state. For instance, if you have a web forms process, and people have
some forms open, if you publish to that same virtual directory, the next time a button is
clicked on the open forms, an error message will display. This is also the case for
Workflow processes. If a person is in a Dialog Workflow step and has a form open, the
next time a button is clicked, an error message will display. But if a workflow process is
at a workflow step and you publish to its virtual directory, nothing is lost since the
process was at rest.
The good news is that the process data is not lost when you publish to the same virtual
directory. The only information lost was the data being entered into the form at the
time.
So when making changes to a project, if the process is going to the same virtual
directory, you need to consider the project type. If the process is a Web Forms project
type, you do not need to be as concerned about impacting “in process” processes even
though you are overwriting the virtual directory contents. This is because Web Forms
processes are stateless; these types of projects simply launch when initiated, present
the user with a form to fill out, hand off data to another process, and end. They do not
have prolonged execution like a Workflow project type that can remain “in process” for
an extended period of time, collecting data along the way. However with Workflow
projects, more consideration needs to be made, as explained in the following section.

Symantec® ServiceDesk Customization Guide 7.0 16
Development Considerations When Publishing to the Same
Virtual Directory
An updated URL application property should not break an “in progress” process that
uses the old URL. Breaks to processes in this state are more likely caused by changes in
the process itself that causes incompatibility, such as a piece of missing data.
The way to mitigate incompatibility is to properly build the new version. For instance,
say you have a process with two Dialog Workflow components. In the first one, you
collect “Name” and “City of Birth” from the user. Then in the second Dialog Workflow
component you display this information to a manager.
Now you want to update the process because of a new regulation. Therefore, in the first
Dialog Workflow component, you also start collecting “Age.” In the second Dialog
Workflow component, you add a rule that shows the manager a warning form if the user
is 13 or younger. If you simply add this rule, then all submissions that were made before
“Age” was collected will be broken. The manager will open his/her task and get an error
saying “object reference not set to the instance of an object,” because “Age” doesn't
exist.
So, to write the new version correctly, you need to add a Variable Exists rule to make
sure “Age” exists before hitting the rule that evaluates age compared to 13. If you
wrote the second version properly, there should be no risk, since all the instances that
were already submitted without age would not break, and all the new instances that
were submitted with age would work.
Basic Steps for Versioning
To publish & version a ServiceDesk process in Symantec Workflow
(simple versioning method)
1. Create the new version of the project by either copying an existing project, or
unpacking the original and renaming it as desired. For example, append a version
number to the name, such as “SD.RoutingRules_2_0.” Leave the Generate New
Service ID checkbox cleared, otherwise the link between the process and
ServiceDesk is broken.
2. Modify the project as needed. Make note of the type of the project. Also, decide
whether the process will be published to the same virtual directory as the current
process. The type of project determines if you need to build in rules to handle new
data. The same applies to publishing to the same virtual directory.
3. If it is the first time a project is being deployed, it is necessary to select the Process
Manager publishing method, either “Publish to Process Manager Forms” or “Publish
to Process Manager Services.”
If using a new virtual directory, enter the desired directory in the Virtual
Directory field. For example, if the old process is in a virtual directory called
“SD.RoutingRules,” call the new virtual directory “SD.RoutingRules.2.0.”
The rest of the default settings are acceptable.
Select the server where you would like to publish your changes and click OK.
4. From the Application Properties Editor screen, note the new Base URL to Project.
Copy this link.
5. Click on Save and complete the publishing process. If prompted, answer the
following:

Symantec® ServiceDesk Customization Guide 7.0 17
Open deployed project --> No
Deploy workflow to NS as DialogWorkflowItem --> No
6. If you changed the name of the project, or if you are using a new virtual directory,
to make the new process active in ServiceDesk, it is necessary to repoint
ServiceDesk so it uses the updated URL. Log in as Admin and go to the Admin tab >
Data > Application Properties.
7. Click on the Actions button (orange lightning bolt) for ServiceDeskSettings and
select Edit Profile Definition.
8. Select Edit Settings from the Actions button.
9. Update the appropriate URL field, and click on Save. The application properties take
about 45 minutes to propagate.
About Application Properties
ServiceDesk knows which Symantec Workflow processes to invoke based on the URL
fields populated from the Admin tab > Data > Application Properties screen. The data in
these URL fields, along with several other pieces of information configured here, are
called application properties.
Processes “in progress” look to Process Manager for their application properties,
(individual processes do not store application properties).
Note:
See the Process Manager (ServiceDesk) Database (page 9) section for an explanation of
the Process Manager.
Updates made to the application properties are not immediately applied to Process
Manager; this is because Process Manager relies on cached application properties. (You
can force the new application properties by restarting IIS, thus clearing the cached data,
but this is not usually feasible in a production environment.) Once Process Manager
updates its cache, then the current processes will start to use the new application
properties.
By default, Process Manager updates its cache every 45 minutes, and is set under Admin
> Portal > Master Settings > Optimization > Clean Cache Time.
This means that if you update a URL field application property with a new process URL, it
does not immediately impact live processes.
Restoring ServiceDesk Processes
ServiceDesk comes with Workflow packages that are unpacked when launched. The
original package content is retained, unless a user intentionally overwrites that package.
Therefore if you need to revert to the original project, simply unpack the project again.
The Workflow Designer also saves backups of a process upon each save, up to 10. Best
practice is to save your changes periodically (i.e., not after every change) in order to
have meaningful backup copies. These copies are stored in a Backup directory: Program
Files\Altiris\Workflow Designer\WorkflowProjects\Backup.
If you need to obtain the original packages that shipped with ServiceDesk, rerun its
installation.

Symantec® ServiceDesk Customization Guide 7.0 18
Project Differential Tool
NOTE:
This tool is not yet available in the released version of Symantec Workflow, but should
be available in the future.
The Workflow Differential tool takes a baseline project and a secondary project and
compares the two, identifying the differences. Use this tool as a first step to identify
changes when troubleshooting a project.
The first project selected in the tool is the project to which a second project is
compared. Any changes to the following in the second project are identified:
zthe libraries the projects utilize,
zProject properties,
zProject resources,
zProject models,
zComponents’ settings or names.
To open the Project Differential tool in Workflow Solution 7, from the Projects list, select
Advanced > Compare Projects. Follow the prompts to select the baseline and secondary
projects. If desired, use the import feature to select which changes you want to import
into the destination model.
Basic ServiceDesk 7 Customization
Editing the Core ITIL Processes
When you open the core ITIL projects from packages, (for example,
SD.IncidentManagement, SD.ChangeManagement, etc.), the process name by default is
the file name of the package.
IT IS NECESSARY TO ADD A SPACE in between “IncidentManagement,”
“ChangeManagement,” etc., within the name of the project being unpacked. If you do
not add a space, and simply accept the default process name, then you would see two
entries for incident management in ServiceDesk, "SD.Incident Management" and
"SD.IncidentManagement." (The name of the process shows on the “My Task List” tab,
for example.)
Verify Users, Groups, and Organizations
ServiceDesk 7 should automatically read users, groups, and organizations from the
Active Directory domain if one was specified during the installation. Log in to
ServiceDesk 7 as the administrative user and go to Admin > Users > Accounts >
Manage Users page and take a look at the information to see if it appears correct and
complete. Administer users, groups, and organizations as needed. Symantec
recommends using groups as the primary way of maintaining permissions.
ServiceDesk 7 comes with default groups to which you can add users. (During
installation it is possible to map existing AD groups to these default groups.) The groups
and associated permissions are defined in the ServiceDesk 7 User Guide.

Symantec® ServiceDesk Customization Guide 7.0 19
If native authentication is to be used solely, without Active Directory, it is necessary to
add users manually to each respective group.
If you create a new group in ServiceDesk, it is necessary to manually add that group to
the application properties in ServiceDesk in order for that group to show up as available
data in Symantec Workflow. This step is what makes the new group show up in the
profile properties list in Symantec Workflow. (Note: the term “application” is
synonymous with “profile” properties in Symantec Workflow.)
To add a new group to the application properties:
1. Create the new group from Admin > Users > List Groups.
2. From the Admin tab, go to Data > Application Properties.
3. Click on the Actions button (orange lightning bolt) for ServiceDeskSettings and
select Edit Profile Definition.
4. Click on Next.
5. Scroll down and click on Add Definition Value.
6. In the Name field, enter the name of the new group. For example,
“GroupSupportIII.”
7. Enter “User Groups” as the category.
8. Leave the data type as text. In the Default Value field, enter
“SD.IncidentManagement.”
9. Click on Save.
10. Click on Finish.
11. If the new category does not appear in Symantec Workflow (for example, when
browsing the profile properties in SD.IncidentManagement), try restarting IIS and
reloading the Symantec Workflow project.
Set Up Incident Categories (Classifications)
A good category system is key to building a smoothly running ServiceDesk 7 system.
Some of the more useful ServiceDesk 7 reports are sorted by category to help you see
what types of issues are most common and what trends are occurring in your
environment.
ServiceDesk 7 ships with a list of suggested categories found under Admin > Data >
Hierarchy Data Service. (These are the same default categories used in Altiris HelpDesk
6.5.) Change the list as much as you want. Up to 10 category levels can be used. You
can also import categories used in Help Desk 6.5 during installation or afterwards, from
the Service Catalog.
Remember that the more complex you make the category system, the harder it might
be for ServiceDesk 7 workers to correctly categorize incidents. If workers don’t
categorize incidents correctly, then steps in your processes may be skipped, or the
wrong steps processed, or an incident could be routed incorrectly, for example. (The
ramifications will depend on the customizations you set up surrounding categorization.
Out of the box, categories are simply pieces of information assigned to an incident and
no affect is made to workflow.)
Remember that best practice is to not delete a category once you start using it because
there is the possibility that an incident is assigned to that category. The incident would

Symantec® ServiceDesk Customization Guide 7.0 20
not be removed, rather it retains the old category, and therefore would be left out of
reporting and search results if only the new category is used.
Note About Imported Categories
Imported incidents maintain the categorization originally assigned. Imported categories
are available for incidents going forward. Imported categories do not map to the default
categories in ServiceDesk 7 and therefore some cleanup may be required (i.e., removing
categories that seem redundant or not needed).
Verify Default Priority, Impact, and Urgency Values
The Priority, Urgency, and Impact fields of incidents can help you manage Service Level
Agreements and comply with the concepts of ITIL service management.
The Priority and Urgency fields indicate how quickly an issue should be resolved. The
Impact field indicates how broad an issue is. Impact could be low if just one person is
affected, or it could be high if the whole organization is affected.
ServiceDesk 7 ships with the following values for these fields:
zDefault priority values: Emergency, urgent, high, normal, minor, low.
zDefault urgency values (on the incident submit form shown to end-users): No
Immediate Urgency, Preventing Some Non-Urgent Work, Blocking Critical Business.
zDefault impact values (on the incident submit form shown to end users): Single
User, Entire Team or Group, Entire Department, Unsure.
zDefault urgency values (to technicians): Core business service, Support service, and
Non-urgent services.
zDefault impact values (to technicians): Department/LOB/Branch, Small group or
VIP, and single user.
Note:
You can change the values, however doing so requires caution and a good
understanding of the Symantec Workflow software.
The instructions below focus on impact and urgency additions to Incident Management;
if you decide to make priority, impact, and/or urgency changes truly global, so they also
apply to Change Management and/or Problem Management, you will need to make
many more updates than what is instructed below.
Changing the priority values is likely the most challenging edit, as "emergency, urgent,
high, normal," and "low" are hard-coded throughout the Symantec Workflow projects for
ServiceDesk, moreso than impact and urgency values. Change priority values only when
absolutely necessary.
This example will add "Financial Group" as a new impact, and "No Internet Access" as a
new urgency value. (Please note that “Financial Group” is not a group of users in
ServiceDesk, rather a group of employees in a company used as an example.)
First, we will add these values to the form that the end-user uses to submit an incident.
Use this example as a model when editing urgency, impact, and priority.
To add new impact and urgency values
1. The technician urgency, impact, and priority values are set as application
properties, under Admin > Data > Application Properties. Log in to ServiceDesk as
the administrator, and go to Admin > Data > Application Properties.