Outline for discussion
Alan lovell Page 1 Service Logbook - Outline
In order to trace the desktop and Computer Centre equipment at CERN, from purchase through to
obsolescence, a service logbook is required. This document was prepared following some initial
discussions with A.Silverman, M.Larsson and T.Whibley and is intended as an outline only, to form a basis
for further discussion.
The following is a list of the various areas from where key information will be obtained. All of the
information will be copied to and stored ion the main service logbook form. This is necessary to allow the
workflow to detect any changes to be entered in the history trace.
IT/CH database Order information, Initial Configuration, Warranty
Information, Serial Number (?), lists of support
hardware used to create menus for the various
WHO Owner and Responsible details, Location
LANDB Network details, Owner and Responsible Details,
PRMS Intervention Details for desktop systems
ITCM Intervention Details for central systems
Input and update of the information will require extra effort on the part of the contract staff as a certain
amount may require entering by hand. Hardware/Software changes and upgrades will need to be entered by
hand, as this information will not be recorded elsewhere.
To Information Transferred
CERN Inventory Updates where discrepancies are seen. The updates
will be sent via the divisional delegates, as we will
not have write access to this database.
History Trace Form All changes to Hardware/Software/Network
Fields in the Form
The logbook should provide the following information:
Staus - On Order, In Service, In Repair, Trade In, Scrapped
Alan lovell Page 2 Service Logbook - Outline
Details of purchase information
TIP Number from IT/CH database
Order Date from IT/CH database
Delivery Date from IT/CH database
Details of ownership, both the owner (or current user) and the person responsible for the equipment.
Owner Name, First Name, Email address, Telephone number. This information should have the
possibility of being completed from the CERN phone book. The lookup should be available after
completing any of the fields.
Responsible Name, First Name, Email address, Telephone number. This information should have
the possibility of being completed from the CERN phone book. The lookup should be available
after completing any of the fields.
Permanent (or usual) location - Building and Room number. To be filled from Owner details in the
Current Location (if the equipment has been relocated for a temporary period) - Building and
Computer Centre X,Y,Z coordinates
System Details. Tis information should be completed automatically (if possible) from the database
maintained by IT/CH database.
Serial Number (from IT/CH database?)
# of CPU
Operating System (Primary OS)
Operating System Release - Could be used for statistical analysis or for rolling upgrades to a new
Secondary Operating System - for dual boot systems
Secondary OS Release
Network Details. To be completed and updated from LANDB.
Hostname. This field should be used as the lookup from LANDB. Entering the hostname followed
by a carriage return should force the update of the network information.
Connection Type - Desktop, DHCP, Visitor or Home
WARRANT Information - Start Date, End Date and Expiry Warning Date. A warning should be sent
to the responsible (and owner?) either three months (automatic) or on a preset date before the warranty
A page field containing the following:
From PRMS (better name). This field will, on refresh, list all of the PRMS cases that refer to the
hostname of this system. It will give single line entry for each PRMS case summarising the
Modified Time, who the case was last modified by (this will often be the AR_ESCALATOR as
Alan lovell Page 3 Service Logbook - Outline
normally the last action on a request is the auto close), the Case ID and the short description. NB: it
is not possible to include the Details, Worklog or Solutions fields in a table of this kind, however
clicking on the Case ID in the Case ID column will open a window displaying the relevant report.
From ITCM (better name). This field will, on refresh, list all of the ITCM cases that refer to the
hostname of this system. It will give single line entry for each ITCM case summarising the
Modified Time, who the case was last modified by, the Case ID and the short description. NB: it is
not possible to include the Details or Worklog fields in a table of this kind, however clicking on the
Case ID in the Case ID column will open a window displaying the relevant report.
Hardware Changes. Whenever any of the hardware or network details are changed a record of
these changes will be stored in another form and this page will contain a single line entry for each
Software Changes. Whenever the Operating system software is changed or upgraded
Network Changes. Whenever the network information is modified.
Last Modified Date
Last Modified By
All of the above fields should be read/write and permanently stored in this form. This form should then
give the valid current status and the related forms will provide the full history information.
Menus of hardware types, memory types, disk types, monitors etc. should be provided. Can these be
updated from the lists of currently supported equipment in the IT/CH database?
A lookup should be provided in the CERN inventory based on the hostname for this system. This will
display the configuration as recorded there. A facility will be provided whereby the support staff may
extract the differences and send an update message to the divisional responsible concerned. List of
divisional responsibles available?
The LANDB will be used by this form as a reference and it should not be necessary to provide updates to
All of the desktop and CC systems will normally be installed with the standard CERN environment,
however there are systems with special requirements. These systems will often have additional software
installed. Should this be traced in the logbook and to what level? Some of this software will use licenses,
which are supplied by a central server, and some will require locally installed software keys. Should the
service logbook contain information on the servers and local keys? This would have security implications
but would simplify finding this information at a later date (many people lose the license keys for their
Alan lovell Page 4 Service Logbook - Outline
locally installed packages. If this information were to be tracked, there are definite advantages, an
additional table field would be required with entries for Package Type, Package Version Number, Licence
server and Licence Key.
The layout in this proposal is similar to the PRMS form and all field names are compatible. The main,
current, information can be seen at a glance and the history information is available in table fields at the
bottom of the form.
Alan lovell Page 5 Service Logbook - Outline
Alan lovell Page 6 Service Logbook - Outline