Serio Blog

Tuesday, 25 Sep 2007

Widgets and gadgets of the desktop variety are becoming a headache. When they are not swallowing up memory they are proving to be the tiny crack through which virus nasties are slipping.

A quick glance to the right of my screen reveals a pot of virtual tulips that needs a virtual watering, a smiley face tracking my CPU usage, rolling news feeds, a weather forecast for London (not my location, but it's a long story), a notepad and the to do list I couldn’t do without. OK I am the kind of widget addict that support teams running out of thumbs to plug the virus dam could do without

It gets worse. Turns out gadget fans may be inviting all sorts of horrors on to their PC that are finding their way on to the network and putting network security at risk. True widget warriors who like to customise their desktops daily may remember that some come with a health warning – “Google has not tested this” etc.

Finjan’s Malicious Code Research Center tracks the latest top priority security threats and has found that widgets and gadgets are vulnerable to a range of attacks. These findings did spark a few security advisories by major vendors who rushed out patches, and an overhaul of the security models used to host these widgets and gadgets online as well as in operating systems.

Finjan found problems with Windows Vista contacts sidebar, Live.com RSS feed and the Yahoo contacts widget. All these vendors have since fixed these problems.

Yahoo told its widget users about a security issue, commonly referred to as a buffer overflow, in an ActiveX control in the Summer. This is part of the software package downloaded with Yahoo! Widgets. Users were asked to download a security patch but those that haven’t remain vulnerable.

A buffer overflow might cause applications to crash but Yahoo points out this could only happen if an attacker is successful in prompting someone to view malicious HTML code, such as by getting a person to visit their web page.

Microsoft has recognised the problem and has guidelines for secure programming best practices for building Windows Vista sidebar gadgets. Its developer network blog points out that, the Windows Vista sidebar hosts gadgets built from HTML, JavaScript, and potentially ActiveX controls, and because gadgets are HTML, they are subject to scary cross-site scripting style bugs allowing script in the sidebar to run arbitrary code on the locally logged-on user’s PC.

It advises us not to trust input and validate and sanitise untrusted input. Obvious you might think but clearly too many of us are ignoring the “not from a trusted source” notices.

Interactive widgets – the really useful ones that rely on external feeds - present the greatest risk offering a free ride to malicious code. It looks as if the time has come to block widget and gadget application file types at the gateway to the business if networks are to be kept secure. 

Thursday, 20 Sep 2007

This is a continuation of Monday's post about Backup Basics.

There are different types of backup

Think for a second about how databases work. They typically have a large pool of data to deal with that doesn’t change that often (like all of your resolved Incidents) and then smaller amounts of new data and data amendments to record, which it needs to store as quickly as possible. The way that such systems handle this is by having a Transaction Log, which is where all the changes go.

Think for a second about that this means. It means you could take a backup of the data that does not change a lot, and then just keep backing-up the Transaction Log so that you are backing up all of the changes you’ve made.

So, SQL Server has two types of backup. There’s the Full or Complete backup, and the [transaction] Log backup. One backs up everything, and one backs up data changes.

So why bother? The answer lies in frequency of backup. Full backups can slow down your system, simply because the database has a lot of work to do is gathering and then writing all of your data. So, these are typically done just once, when the database is quiet (like late in the evening). The rest of the time, you perform Log backups to record your changes because this is much quicker, and places less of a burden on the system.

Tip: Don’t perform multiple Full backups during the day – your users will notice, particularly if you have a large amount of data.

If the worst happens, you restore from your last good Full backup, and then perform rollforwards using the backups you’ve taken of the Log – effectively re-applying all the changes you made.

When you perform your SQL Server backup, one of the things you can choose to do is to truncate the Transaction Log (otherwise, on SQLServer, it will just keep on getting bigger).

Frequency of Backup is Important

If you do your backup once a day, think about how many hours of data you could lose if it all goes pear shaped – almost a day’s worth. As a manager, think about your Helpdesk or Service Desk’s throughput during the day and how much data you could ‘afford’ to lose, and then build your backup strategy around this, for example by having a Full backup during the day, and an hourly Log backup during the day. Remember, don't rely on fault-tolerant hardware. If there is a fire, theft, or one of the engineers spills his bottle of Irn Bru over the server, you could lose everything in an instant.

Using 3rd-party software

Using third party utilities and software to backup your database is fine, provided you choose wisely. However, don’t think that will necessarily excuse you from understanding the issues I’ve highlighted above. All such programs that I’ve seen simply provide convenient interfaces to SQLServer’s own backup mechanisms – so everything I’ve said above still applies. You still have to think about frequency, type of backup and log truncation.

Practice, Practice, Practise

Have you ever practised recovery? Don’t make your first recovery a real recovery – practice will prove that your backup and recovery procedures are effective. Don't trust to luck.

A Word of Caution to Managers

Users tend to hold senior managers responsible for data loss. Take an interest in your backup and recovery procedures, and don’t assume it’s all been taken care of.

Monday, 17 Sep 2007

This is a follow-on from Friday’s post about Backups

Database Backups – The Basics

Serio, like many systems, stores most (but not all) of it’s data in a relational (ie, table based) database which can be either Oracle or SQL Server. I’m going to talk about SQL Server, but most of this applies to Oracle as well. So when you log an Incident, it’s stored in a the database, when you compose an email, it's stored in the database, and on - pretty much all of the content you create is stored there.

Serio doesn’t actually write to the files. Instead, Serio says ‘here’s an Incident, store it somewhere, I don’t want to know where’ and this SQL Server duly does. Then it sits waiting for the next instruction.

All the time SQL Server is waiting, the files that it uses (of which there are quite a few) are held open, and the contents might be in what you could call an inconsistent state – in the middle of being written to, read from, reorganised or generally tidied as the database processes requests.

From a backup point of view, this means you cannot just leave the database running and then copy the files onto backup medium, because you never know what state they will be in (even if you can read them, because they are usually opened with exclusive access).

If you think this is so obvious it’s not worth pointing out, I’d bet there are people reading this who ‘backup’ by doing exactly that.

Shutdown & Startup Backups

Of course, you could shut the database down (say overnight) and then copy those files. This may work just fine (but it's something I regard as ill-advised and risky), but it’s inconvenient and can lead to large data loss. It’s inconvenient because you first of all have to shut down the applications using the database, then shut the database down, then backup, and then re-start everything.

The data loss comes about because this type of backup is typically done once every day (at night). So, if you have a system failure towards the end of the next business day, you’ve lost a day’s worth of data. Maybe you think that's OK for your environment, but to me that seems like a lot of work and information to discard.

Usually, this type of strategy is adopted by those that are not comfortable with their database tools.

Better Backups

Backing-up your database is best done by saying to the database ‘back yourself up’. The output from this command is usually a file (in SQLServer’s case), that you simply place on different (safe) media. If the worst happens and your own server starts to go ‘boing…’ (see my last post for what I mean) when it is powered on, you take this file and recover using it – buy telling the database to restore from backup file.

This kind of approach is superior to the shutdown and startup backups I’ve mentioned above for another reason – during this process of backing itself up, the database will check it’s own integrity – so if it has any internal issues you may hear about these sooner rather than later (which is a good thing).

I'll post about Full backups and the Transaction Log shortly.

Friday, 14 Sep 2007

Just how good is your backup regime? A colleague here at Serio tells this story.

I managed a direct sales IT system. It was a very busy environment – people asking for new reports, account managers shouting, IT staff either leaving or threatening to leave – and often I simply followed the current crisis (whatever that was), having been in the job for just a few months.

One of my first projects was to move our direct sales system onto a new ‘fault-tolerant’ system. This went well, and I delegated the task of ‘sorting out the backups’ to one of my team who was not in the process of leaving that week. I never thought any more about it (the backups), after all I had delegated it.

One Thursday morning. I came into work at 8:00am as usual, and our new server was making a funny noise, in that when you switched it on it went ‘boing...’, and then refused to boot. With increasing panic, I switched the machine off and back-on, hoping for a boot-up, but all it did was go ‘boing...’. I even tried pushing the 'on' button slowly, like that would help.

An engineer was called, who pronounced the RAID system and one of it’s disks ‘toast – never seen a problem like it’ he said. ‘It’s not that fault tolerant’ he added helpfully.

Worse was to come. I scrambled for the backup, only to find that the entire Oracle database had been skipped from the backup tape because the files were busy, as the database was still active of course. Also by this time customers were phoning, the call centre was operational (in that it had staff answering the phone).

We had £50,000 approx (a usual days trading) of unfulfilled orders. Many orders part-shipped, some ready to go, stock to be booked in things looked grim. How was I going to explain we had no backup, and all was lost? A posse of account managers was waiting outside my office. They looked mean and angry, especially the females.

Just then, ‘the new guy’ came in, who joined us no more that a fortnight earlier. ‘Wassup?’ he says? I explained.

‘Oh, I’ve got a backup here from last night. I couldn’t see any decent backup so I did a full Oracle export to network filestore, using cron to schedule the job’. And sure enough, there it was – I wasn’t going to get fired after all, although I probably deserved it’.

I relate this story for the simple fact that every backup mistake you could make is in this story.

  • Failure to plan for backup and recovery
  • Managerial delegation of responsibility with inadequate checks or verification
  • Over-dependence of ‘fault tolerant technology’ leading to complacency
  • Failure to understand how to backup his software.

I’ll post some information on Monday about the correct way to approach backing up your database system, focusing in particular on SQLServer, the types of backup, transaction log and so on.

(With thanks to AndyW for input).

Tuesday, 11 Sep 2007

This is a follow-up to my earlier post about Change Plan Templates (CPT), which mentioned that the major elements of a Change Plan were

  • Stages
  • Tasks
  • Durations for Tasks
  • Branching
  • Interested parties
  • Special Actions

Stage

A Stage is a major (actually, the major) element of a Change process, and will include at least one Task (see below), but will often include a number of Tasks. Think of it this way: take whatever you are trying to accomplish (for example, ‘Server Operating System Upgrade’) and then subdivide this into it’s major parts (such as ‘Authorisation’, ‘Scheduling’, ‘Testing’) and these will typically constitute your Stages.

Task

A Task is simply something that someone does. For instance, an Authorisation Stage (see above) might have 3 Tasks – one for each of the members of the Change Advisory Board (see my previous postings on this subject).

The thing about Tasks is that they should be self-contained – everything that people need to know on how to complete the Task should be included for them (actually, defined when you set-up the Change Plan Template).

Don’t go mad with your Change Plan Template & Tasks

If you are in the process of setting-up a Change Plan Template for the first time, stop for a moment. Are you micro-managing? Micro-management of staff involved in Change is one of the commonest mistakes I’ve seen.

Micro-management will make your CPT much harder to maintain, and may cause your colleagues to view the Change process with disdain. It’s much easier if you assume that those participating in the Change are

  • Properly trained and able to perform their jobs
  • That they have some common sense
  • Are generally supportive of IT Service Management within your organisation

(if it’s not safe to assume these things then you have some work to do outside of Change Management).

To give some examples real of micro-management I’ve seen recently:

A Change involving a software update that had a whole Task for ‘Download patch’ when it was in a vendor website that said ‘click here for latest patch’, and then followed this with a Task for ‘Unzip Patch’.

Change that had a Task called ‘reboot server’ as part of an operating system update.

The above are examples of micro-management because there is series of menial Tasks and a heavy administrative burden, and an assumption that the engineer is too daft to do the job in hand correctly.

Checklists are cool

If you have a Task that requires quite a few things to be done, and you want to make sure that these are all accomplished, the best way to accomplish this is through a checklist. When you set-up the Task, include a simple checklist for those who will be working on the Change. It’s easier to create, and of more value to engineers.

I’ll post about the other parts of a CPT later.

Remember that for full documentation on the Serio Change subsystem, consult the HowTo guide distributed with Serio products.

Friday, 07 Sep 2007

In today's post, I'm going to introduce you to SerioScribe, Serio's screen customisation tool for both SerioClient and SerioAdmin.

Naturally, we've put a lot of thought and research into the design of our screens, and if you're like many of our customers, you'll probably find that you don't ever need to change them.

That said, specific reporting or management requirements occasionally require people to, for example, put additional fields to the logging form. At other times you might want to: streamline forms by hiding fields you never use; adjust the tabbing order according to your data capture process; move fields around; change the labels on fields to conform with your organisation's terminology or to change the use of a field; disable fields to prevent certain users from modifying them, or make others mandatory; change colours/fonts or add special instructions; remove menu options in SerioClient.

A Word of Warning

Don't hack your screens to pieces, hiding fields you just haven't happened to use yet, and leaving the others higglety-pigglety. Also remember that Serio uses industry standard ITIL terminology, so think carefully before changing it. Customisation is like a drug for some people – remember: less is more!

Example

Each Incident received by the Service Desk at WXYZ PLC relates to a particular project. All the projects generate the same types of calls, and WXYZ have set up Problem Areas and Cause Categories to reflect these. As a reporting requirement, they also need to be able record the project code against each Incident. They decide to add a custom lookup field (Project) to the logging form for this purpose.

How to do it!

1.If you don't already have it, install SerioScribe – it's an option in the setup program in the main 'Serio' folder from your Serio software.

2.Choose 'File' > 'Login' to log on to SerioScribe – you can use the same login as you do for SerioClient.

3.Open a new Screen Explorer from the 'File' menu.

4.Look under 'Screen Sets' in the explorer pane. Most Serio installations have at least one Screen Set already set up (usually 'Default'). If you don't have any, right click on 'Screen Sets' and create one.

5.Expanding your screen set, you see that it's divided into SerioClient and SerioAdmin screens. Using multiple Screen Sets, you can create different customisations for different groups of users, but most users only need the one.

6.Expand the 'SerioClient Screens' and select 'Incident Logging'. At this point, you'll notice there's another Incident Logging screen called 'Incident Logging (Incident Management)'. This latter version of the screen is used when you are view Incident details after logging, through 'Manage' > 'Incidents'. The 'Incident Logging' field is shown when logging new Incidents. In this case, we want to apply the change to both versions.

7.At the bottom of the 'Incident Logging' form, you'll see the custom 'Lookup 1' field. Right click on the label, and choose 'Properties'. Change the text of the label to 'Project:', and make the label visible.

8.Now right click on the (white) data entry field, and make it visible – also set 'Must complete:' if necessary. Switch to the 'Lookup' tab page of the properties dialog, and set the Windows Title, Left Column Title, and Right Column Title to 'Projects', 'Project', and 'Project Description' respectively.

9.We're not going to use the blue read-only description field to the right of the custom lookup 1 field this time, so leave it as it is. Drag the label and lookup field, e.g. to the convenient gap between the 'Impact' and 'Received' fields.

Tip: You can multiple select using Shift+Click, and align your selection using the 'Control' menu.

10.Turn on the 'Show Tabbing Order' from the 'Control' menu, and sort out the order that your new field will be tabbed to.

11.Make the same changes as above to the 'Incident Logging (Incident Management)' version of the screen.

12.While you're adding your Project field, you might want to make sure it appears correctly elsewhere. You can have it as a column in the Selected Incidents field. To set the title of this field to 'Project', follow the instructions in the help in SerioScribe. In the help, turn to the 'Contents' tab page and see the topic: 'SerioScribe Help' > 'Common Customisation Tasks' > 'Changing the Issue Monitor Column Headings'. The column headings you need to change in this case are 'Issue Lookup 1' and 'Issue Lookup 1 Description'.

13.You can also set the name on 'Issue Selection Criteria' screen for selecting Incidents. Select this screen in SerioScribe – you'll notice it consists of a number of different 'pages'. Scroll right down to the bottom - the Custom issue lookups are shown on the third page from the bottom.

14.Ok, now you need to make sure that users can see your customisation. In SerioAdmin, open a New Serio Explorer from the 'File' menu. Expand 'Agent' and select 'Profiles'. Open up your profile and look on the 'System' page. Make sure that the Screen Set that you have been working on in SerioScribe is selected where it says, 'Customise the Agent screens using the following screen set'. Apply the same change to the other Profiles.

15.While you're in SerioAdmin, you can define your 'Project' codes. Do so by expanding 'Issue' and selecting 'Custom Issue Lookup 1'.

16.Log out of SerioClient and then back in to see your changes!

Wednesday, 05 Sep 2007

This is a follow-up post to Creating your First Change Plan Template. This post, about a week later than I was expecting, is on the subject of Change Plan Templates generally, and the role they play in the Change Management subsystem.

As always, remember that this blog is additional, bite-sized info to help people get started with something new. The full documentation on Change Plan Templates and the entire CM subsystem is distributed with the tool itself, in the HowTo guide. That’s where you should go for more info.

Change Plan Templates (CPT)

Let’s talk for a moment about Change Plan Templates. If you are trying to use this Change subsystem for the first time, don’t skip this theory – it will help you to understand later articles and put them into context.

I mentioned in the last post on this subject that before approaching the Serio tool you should have a clear idea of what (in a business and procedural sense) you want to do, what problems you might be trying to resolve, and what you want to acheive. What I’m talking about is the standard way you’d like to handle certain types of Changes – what the major steps are, who is involved, and how long it should all take.

The Change Plan Template is where you store this knowledge about the standard process you’ve defined. When you have an actual Change you need to perform, like applying a server operating system patch of some kind, you take the Template and attach it to a Change so that Serio knows how the Change should be handled. In effect, you're taking a CPT and saying 'for this Change, do this'.

A Test or Training Server

If you want to get started remember that you’ll need a Test or Training Server – so you can learn what needs to be done in an environment that is not live, and will not interfere with live operations or reporting. Serio don’t charge for such server set-ups, so all you need is a Windows 2000 or 2003 machine, and a database server (ideally running a test database which is a copy of your live system).

Components of a Change Plan Template

CPTs are quite complex things. If you are starting out, it might help to think of them as a flowchart on steroids. See Figure 1 for a representation of a flowchart in the tool. Change Control

Figure 1 - Change Control (Serio Flowchart)

What you’ll find inside a CPT are as follows.

  • Stages
  • Tasks
  • Durations for Tasks
  • Branching
  • Interested parties
  • Special Actions

I’ll post later with a definition for each of these.

Monday, 03 Sep 2007

This is a follow-up to last week’s post about basic Helpdesk/Service desk call handling. In this article, I’m going to discuss some strategies and approaches you can take if you simply don’t have enough staff to handle incoming call volumes.

Just to recap, the situation I’m addressing is a chronic shortage of Helpdesk or Service Desk staff to actually answer the telephones and deal with customers – and no budget with which to expand the team.

Secondment.

Making sure the phone is answered is arguably  the most important, visible and (for customers) easily discernible functions of the Service Desk. So it makes sense on the face of it to transfer staff from other functions into this customer facing role.

I am aware this may be greeted with resistance, particularly in organisations which are organised along hierarchical rather than project (matrix) lines. Staff can object because posting to customer-facing teams, and away from technical roles, because they see it as a demotion, or dare I say it seems like rather hard work, or because their focus is narrow and they don’t see the need.

If you anticipate resistance, I can suggest a few things to try:

  • Make the secondment period a fixed interval of no more than one month. My personal preference is something like one to two weeks.
  • Ensure all staff, including managerial staff, take a turn  - even of it’s for a shorter period. This is usually a very effective ‘neutraliser’ of staff disquiet.

A word of caution. Don’t second staff without proper training first – and that training should include some test calls. I’ll also advise you to have a Script – which I’ve blogged about here, and here.

Staff Hours/Lunch Rotas/Start Times

One of the things the telephone statistics I mentioned in the last post will tell you if there is a problem with your service times. For instance, if you get calls at 7:30am but your Helpdesk/Service Desk starts work at 09:00 you may need to look at adjusting your service times accordingly.

One thing I’ve noticed is that whilst many organisations (particularly in the UK public sector) have introduced flexible working hours, the impact on essential support services has not always been thought through fully.

As a normal response to this I’d say ‘produce a costed proposal for increased service times’, however as this post was prompted by someone with no extra budget, the only thing I can suggest is to try to re-negotiate start times – possibly by offering something like an earlier start/finish, skipping Friday afternoons – anything to make the prospect attractive.

Make sure also that there is a clear rota in operation over lunchtime, giving you the maximum possible cover. Again you may find that some staff will trade a shorter lunchtime interval for an earlier finish.

Define the Role of Front-Line Staff Carefully.

Are your front-line staff trying to ‘first-time fix’ or simply take and make calls? If you go for attempting fixes for some or all calls, then naturally the amount of time each calls takes is likely to rise. Make sure staff are clear on what you want them to do, and remember you can vary what you do at different times of the day.

If you really are thin on the ground, it makes most sense to me to concentrate primarily on call taking, with resolutions attempts limited to the most simple of things such as password resets. 

Wednesday, 29 Aug 2007

I’m prompted to write today by a customer who doesn’t have enough staff on their Service Desk/Helpdesk taking calls from customers, and who is looking for any strategies to help cope with this. The business is both outbound and inbound sales order processing, with a user base in excess of 500.

My first response, naturally enough, is to suggest recruiting more staff. However, our customer is adamant that there is no budget for this.

So where do you start?

First of all, you need to understand what your current position is – just how understaffed on the front-line are you? You can normally find this out from your telephone statistics (yes, if you ask the right people you can get statistics from your telephone system).

There are a few Key Performance Indicators (KPIs) you need to look at in this regard:

Number of rings before pickup. My opinion is that anything below 6 is OK, anything above 10 is poor. Look at the average and standard deviations. Ideally you’ll get this in graph form. This is because incoming call activity for Helpdesks and Service Desks exhibits natural spikes of activity at different times of the day and week.

Call Abandonment Rate. This is the number of calls where the caller has given up, and not surprisingly it’s linked to the number of rings before pickup. You can think of this as the number of unhappy and dissatisfied customers you’ve had, and is a major KPI.

Voicemail cleardown. If you use voicemail (for instance, it kicks in if all lines are busy, or picks-up after a number of rings) then this can muddy the waters somewhat. What you need here is the number of voicemail messages left, and the time taken (again displayed in graph form) to delete a message (deletion usually being an indication that the message has been actioned). The reason I say that it can muddy the waters is that is either replaces or distorts the Call Abandonment Rate KPI I mentioned earlier.

These three statistics will give you your current position in terms of call volumes.

I’ll post later about strategies for dealing with this, but before I do that I just want to issue a word of caution. There seems to be a tendency amongst Service Desk Managers to play-down the importance of telephone statistics (‘they can log it through the web, so what's the problem?’), but I think this is a bad attitude. If you offer a telephone service it should be ‘fit for purpose’. In addition to this, some users prefer to speak to someone particularly if the Incident is important to them.

In the case of the customer who prompted this article, it might be a front-line sales advisor who needs to earn commission on sales, but is having problems with their IT system and wants to speak to someone. Whatever the situation, customer perception will be damaged no matter good other service provision might be.

Monday, 27 Aug 2007

This week, I’m going to look at how you go about creating your first Change Plan Template. Before that, it’s probably time for a recap.

I’ve been blogging about Change Management recently. The recent posts have covered subjects such as Change Management Definitions, Change Management Scope and Change Management Process, all in an effort to ‘set the scene’.

The Change Plan Template I mentioned above this the name we give to the whole process you enter into Serio – it defines the tasks, what is meant to happen when, standard times, exception handling – everything you would expect to be included in a standard Change. As always, for full information and documentation, please consult the HowTo guide which is distributed with Serio products – you’ll find an entire book there documenting the Change Management subsystem.

There seems to be a temptation to simply sit down in front of the Change Explorer in Serio and try to ‘create a template’. This is not the right approach! Before approaching the tool, you need to have a clear idea of what process you’ll be following, what will be involved, who is participating, what your reporting will be, and have some agreement with colleagues.

In reality then, you should have something written down before approaching the tool. This might take the form of a simple flowchart or a textual description. Whatever you decide upon, it will be something you can visualise before approaching the Change Template editor.

Working with Affected Teams

One of the big challenges facing a Change Manager is the fact that he or she might be changing the way that individuals and teams work both with themselves and with each other. The most obvious example of this is when there is no Change Management process in place at all, and so staff that have been able to entirely control whatever tasks they perform suddenly have a process ‘imposed’ on them, causing ill-feeling and conflict.

It’s usually advisable for the Change Manager to work with affected teams. My advice to customers is to avoid working with the team as a whole, but to select one ‘Champion’ or ‘representative’ to work with the Change Manager in developing a process, who can make decisions on behalf of their team (my experience has been that large groups are not good at decision making).

In summary, Change Managers have to be able to work effectively and communicate well with different groups, and handle situations calmly where people don’t see eye-to-eye. It’s not something you can do isolation (though I know some that have tried).

I’ll post later in the week about the key parts of a Change Plan Template.

Pages