Section 4.1-4.3: Documentation, Backup and Recovery

- the best way to manage support requests: document, assign, resolve, report
- usually a responsibility of the help desk: take calls, triage, determine the best next step, assign the ticket and monitor
- there are many different ticketing systems: they're all very similar in function

- information gathering: user and device information, problem description
- applying context: categorization of the problem, assign severity, determine if escalation is required
- clear and concise communication: problem description, progress notes, resolution details

- you can't address a person's problem unless you know who has the issue: add the of the person reporting the problem
- usually integrated into a name service: active directory or similar
- may be added automatically: many issues arrive from a portal or email gateway
- always confirm the contact info: the database may not be up to date

- device information: laptop, printer, conference room projector, etc
- description: one of the most important fields in the ticket, make the description clear and concise
- the description determines the next step: call back for more info, associate with another event, assign to another person

- categories: broad description, change request, hardware request, problem investigation, hardware failure, onboarding, offboarding, etc
- severity: often an established set of standards, low, medium, high, or critical
- escalation levels: difficult or unique problems can be handled by a specialist, escalate to a new tier or to a specific group

- progress notes: many people may read and or work on a single ticket, keep the progress info concise, document any changes or additional info
- problem resolution: document the solution, may be referenced later by others with the same problem, a "live" knowledgebase of issues and resolutions

- a record of every asset: laptops, desktops, servers, routers, switches, cables, fiber modules, tablets, etc
- associate a support ticket with a device make and model: can be more detailed than a user's description
- financial records, audits, depreciation: make and model, configuration, purchase date, location, etc
- add an asset tag: barcode, RFID, visible tracking number, organization name

- a central asset tracking system: used by different parts of the organization
- assigned users: associate a person with an asset, useful for tracking a system
- warranty: a different process if out of warranty
- licensing: software costs, ongoing renewal deadlines

- the purchasing process: multi-step process for requesting and obtaining goods and services
- start with a request from the user: usually includes budgeting information and formal approvals
- negotiate with suppliers: terms and conditions
- purchase, invoice, and payment: the money part

- Acceptable Use Policies: what is acceptable use of company assets: detailed documentation, may be documented in the Rules of Behavior
- covers many topics: internet use, telephones, computers, mobile devices, etc
- used by an organization to limit legal liability: if someone is dismissed, there are well-documented reasons why

- describes the network layout: may be a logical diagram and can include physical rack locations

- meeting the standard of laws, policies, and regulations
- a healthy catalog of rules: across many aspects of business and life, many are industry-specific or situational
- penalities: fines, loss of employment, incarceration
- scope: domestic and international requirements

- a message, logo, or graphic shown during startup or login: can be used for branding or to require compliance
- can be informational: maintenance notifications or system changes
- may be required for legal or administrative purposes: warnings about system misuse, information about relying on application data

- security policy: an ongoing challenge
- documentation must be available: no questions
- incidents are ongoing: organization have formal incident plans
- reports and documentation: details of any security incident, create a reference for future incidents

- organizations have different business objectives: processes and procedures
- operational procedures: downtime notifications, facilities issues
- software installation and upgrades: custom installation of a software package, testing and change control
- documentation is the key: everyone can review and understand the policies

- bring a new person into the organization: new uesr setup checklist
- IT agreements need to be signed: may be part of the employee handbook or a separate AUP
- create accounts: associate the user with the proper groups and departments
- provide required IT hardware: laptops, tablets, etc, preconfigured and ready to go

- end user termination checklist
- this process should be predefined: you don't want to decide how to do things at this point
- what happens to the hardware, what happens to the data, account info is usually deactiviated: but not always deleted

- external sources: manufacturer knowledge base, internet communities
- internal documentation: institutional knowledge, usually part of help desk software
- find the solution quickly: searchable archive, automatic searches with helpdesk ticket keywords

- how to make a change: upgrade software, patch an application, change firewall configuration, modify switch ports
- one of the most common risks in the enterprise: occurs very frequently
- often overlooked or ignored
- have clear policies: frequency, duration, installation process, rollback procedures
- sometimes extremely difficult to implement: it's hard to change corporate culture

- you should always have a way to revert your changes: prepare for the worst, hope for the best
- this isn't as easy as it sounds: some changes are difficult to revert
- always have backups

- isolated testing environment: technological safe space
- use before making change to production: try the upgrade, apply the patch, test and confirm before deployment
- confirm the rollback plan: move everything back to the original, a sandbox can't consider every possibility

- a team effort: many different parts of the organization
- IT team: implements the change
- business customer: the user of the technology or software
- organization sponsor: someone's budget is responsible for the process and or responsible for the profit

- a formal process for managing change: avoid downtime, confusion, and mistakes
- nothing changes without the process: complete the request forms, determine the purpose of the change, identify the scope of the change, schedule a date and time of the change, determine affected systems and the impact, analyze the risk associated with the change, get approval from the change control board, get end-user acceptance after the change is complete

- a formal process always seems to include a bit of paperwork: this is usually an online system
- nothing gets missed: easy to manage, create detailed reports and statistics
- usually a transparent process: many different groups and people are usually involved

- why are we doing this: there needs to be a compelling reason
- application upgrades: new features, bug fixes, performance enhancements
- security fixes: monthly patches and vulnerability fixes
- there needs to be a good reason: changes are costly

- determine the effect of the change: may be limited to a single server or an entire site
- a single change can be far reaching: multiple applications, internet connectivity, remote site access, external customer access
- how long will this take: specific date and time for the change, may have no impact, could have hours of downtime

- determine a risk value: high, medium, or low
- the risks can be minor or far-reaching: the "fix" doesn't actually fix anything, the fix breaks something else, OS failures, data corruption
- what's the risk with NOT making the change: security vulnerability, application unavailability, unexpected downtime to other services

- lots of discussion before deciding if change is necessary
- all important parts of the organization are represented: potential changes can affect the entire company
- some changes have priority: the change board makes the schedule, some changes happen quickly and some take time
- this is the last step: the actual work comes next

- nothing happens without a sign-off: the end users of the application or network
- one of your jobs is to make them successful: they ultimately decide if a change is worth it to them

- very important: recover valuable data, plan for disaster
- many different implementations: total amount of data, type of backup, backup media, storage location, backup and recovery software, day of the week

- backup everything: all OS and user files
- this is usually the longest backup process: its everything in one backup
- might be impractical every day: long backup times, lots of storage space

- a full backup is taken first
- subsequent backups contain data changed since the last full backup: these usually grow larger as data is changed
- a restoration requires the full backup and the last differential backup
- recovery only takes full backup and the last differential backup that has built up over time

- a full backup is taken first
- subsequent backups contain data since the last full backup: these are usually smaller than the full backup
- a restoration requires the full backup and all of the incremental backups

- create a full backup: without actually performing a full backup
- the first full backup copies every file, subsequent full backups are created from previous backups
- can be faster and less bandwidth intensive: the advantage of a full backup and the efficiency of an incremental backup

- Full: all selected data, high backup, low restore time(one backup set)
- differential: all data modified since the last full backup, moderate backup, moderate restore time(no more than 2 backup sets)
- incremental: new files and files modified since the last backup, low backup, high restore time(multiple backup sets)
- synthetic: all selected data, low backup, low restore time(one backup set)

- it's not enough to perform the backup: you have to be able to restore
- disaster recovery testing: simulate a disaster situation, restore from backup
- confirm the restoration: test the restored application and data
- perform periodic audits: always have a good backup, weekly monthly and quarterly checks

- on site backups: no internet link required, data is immediately available, generally less expensive than off site
- off site backups: transfer data over internet or WAN link, data is available after a disaster, restoration can be performed from anywhere
- organizations often use both: more copies of the data and more options when restoring

- grandfather-father-son: three separate backup rotations, monthly weekly and daily
- 12 monthly full backups(grandfather): a good choice for offsite storage
- four or five weekly full backups(father): depends on which day of the month is selected
- 31 daily incremental or differential backups(son): backup any daily changes

- choose a rotation: every organization is different
- grandfather: last day of every month
- father: every monday
- son: monday through friday

- a popular and effective backup strategy: for business or home use
- 3 copies of data should always be available: one primary and two backups
- 2 different types of media should be used: local drive, tape backup, NAS
- 1 copy of the backup should be offsite: offsite storage, cloud backup