From NEOSYS Technical Support Wiki
Jump to navigationJump to search

Here are procedures to be followed by Support Staff in respect to various technical matters in day to day operations of client issues.

Once Support Staff have learnt how to follow these procedures & rules, you then start learning when and how to not follow them. Common sense trumps all rules! i.e. don't follow procedures and rules blindly all the time. Analyse the problem and solve it practically.

BUT if you are doing something off-piste deliberately, then just add an appropriate comment about why you are.

1 Handling Clients with Overdue Invoice

In order to maintain good payment speed by clients NEOSYS needs to restrict support to clients that dont pay their bills on time, however the degree of restriction needs to depend on an intimate knowledge of the client which cannot be expected from all NEOSYS support staff. Therefore we will use a simple escalation policy as follows:

1.1 Overdue Support List

NEOSYS SUPPORT will maintain an overdue list on Thunderbird support inbox. Generally, clients will go on the list immediately when their invoice is overdue and come off only after satisfactory commitment to pay have been obtained.

The latest overdue list email MUST always be starred until there are no clients left on the overdue list (apart from the permanently overdue clients). When a client is added to the overdue list, support must set up a filter to move client support emails to the overdue folder. When a client is removed from the overdue list, client emails must be moved back into the support inbox. This way support team will know that there are still clients on the overdue list and will not mistakenly provide support to those clients.


For the first week of each quarter of the year, normal support should be provided for server failures and backup failures (including hung processes as it could eventually lead to backup failures).

For any other support requests from overdue clients, respond with the following letter (where XYZ is the overdue client):

Dear <user>,
There is an issue with your company's account. We have requested our Accounts team for approval in order to provide support to you and other <company_name> users.

Support staff MUST then provide the required support to the overdue client only after 4 working hours. Support Staff need not actually contact the Accounts team for approval, although that is what is mentioned in the letter. This delay in support is to encourage clients to settle their payments on time.

After the first week of each quarter of the year, respond to any support requests from overdue clients with the above letter but MUST NOT PROVIDE SUPPORT even after 4 working hours. Instead, Support Staff must refer the support request to NEOSYS Support Manager.

Managers may well instruct support to provide support on a case by case basis even if clients are on the overdue list. Being on the overdue list does not necessarily indicate a major issue with accounts.

If the client provides proof of payment (e.g. cheque deposit slip), then carefully check all the details as mentioned in When can NEOSYS support staff start installation of NEOSYS, before getting approval from NEOSYS management to remove the client from the overdue list.

1.2 Handling complaints about Licence restrictions

Sometimes when a client delays payment of NEOSYS invoice, support places a licence restriction for the client. In such cases, users will not be able to create and save documents dated outside the licence period. Due to this sudden restriction, clients may raise complaints about the restriction placed.

Support MUST simply inform them that licence restrictions are a default procedure followed by NEOSYS and is applied to all clients, so that the client will in future avoid delaying the payment.

1.3 Handling complaints about emails from NEOSYS Accounts Department

If a client calls Support team to complain about emails from NEOSYS accounts department (e.g. invoice payment reminder), then immediately make them realise that they are wasting their time talking to support, because support should not involve themselves in client invoices and reminders procedure.

Support: "Terribly sorry, but I handle Support, you will have to contact Accounts."

Client: yaddah yaddah yaddah for as long as they like

Support: "Terribly sorry, but I handle Support, you will have to contact Accounts."

Client: "Can you put me through to Accounts?"

Support: "Sorry, Accounts is not in the office at the moment."

Client: "When can I call to get through to accounts?"

Support: "I'm afraid I don't know."

Client: "Can you get accounts to call me back?"

Support: "I will pass on the message"

2 Handling Frozen NEOSYS Installations and Databases

Some clients retain fully operational NEOSYS installations or just particular databases even after they stop using them for some reason, either because they move to some other software, or because they terminate an operational division, or other reasons, and this can either be on NEOSYS or their own servers.

In this case, various NEOSYS upgrade and maintenance processes may be suspended, downgraded or completely skipped especially if instant access to the server is no longer available. This does not mean that it should never be done, and pros and cons need to be assessed and documented in support emails on a case by case basis.

  • Upgrading NEOSYS version
  • Upgrading/standardising NEOSYS database configuration and other files for consistency, security or other issues
  • Patching Windows/IIS configuration for consistency, security or other issues

3 Handling Links and Email Attachments


These days you can no longer trust links or attachments in emails from anybody - even emails from highly trusted people like your bank.

If a personal computer or intermediate email server is hacked then even genuine emails sent out from it can be infected and modified in a hidden way that can result in the recipient being infected if they click or open anything in the email.

Therefore you should know and understand how to avoid, as far as possible, getting tricked and infected via emails.

Malware authors generally rely on the fact that most people devote no time at all to security precautions so a moderate cautious approach, slowing down a little to spending some time on security, even where it is apparently not required, is enough to defeat most attacks.

3.1 Links

Do NOT click on links, especially in emails that you are not expecting, but also anywhere else that you see links, without taking various precautions. The links in an email, even from someone you know and trust, can LIE to you about what website they will open and they can lead you to websites that mere browsing can infect your computer and then others inside our network.


Therefore, to use a link in any and all emails, first hover your cursor over it and check the status bar at the bottom of the screen where you can see exactly what website will be opened, or, to be more sure exactly what website you are opening DO NOT click links in emails at all. COPY/PASTE the link to your browser, AFTER following the below points.

  • Make sure you know and trust the website being opened.
  • Carefully inspect the spelling of the domain name to avoid tricky look-alike fraudulent links eg instead of
  • If you trust the sender but you do not personally know the website then get independent confirmation from the sender. Reply to the email so that the sender can check the link you received has not been tampered with.

Example 1:

Below is an example of a phishing email that you can easily tell is malware


  • You don't expect it because it says "before your sign up is complete" ... but you didn't just sign up.

This doesn't mean that links in emails that you ARE expecting ARE safe to open. All the usual cautions apply to emails you DO expect.

  • Hover mouse over the button and check the link visually

In the example above, the email is supposed to be from Dropbox, but hovering the mouse over the button shows the below link, which is obviously wrong:
  • Even if the link looks genuine e.g. something from a service that we use that we didn't expect, be careful for misspelt links that look like genuine links e.g., which could trick you if you are sloppy.

Never click on links in emails unless you are absolutely 100% sure that the email and link is genuine.

Copy the link using right click copy link then paste into your browser if there is the slightest doubt.

Example 2:

In the following case, hovering over the first two links seem to go to real UPS website, BUT this is NOT sufficient to be sure since slight misspellings and other tricks can lead you to a totally different website.

However, hovering over the third "link" shows that clicking the apparent link would go to some website:

(Vietnam) so clearly this is a DECEPTION.


Example 3:

In this case, an unknown organization behind the phishing attack is pretending to work for Leaseweb sales company and is sending emails from an email address similar to Leaseweb’s, and with Leaseweb’s footer. They claim that the original payment was declined and ask to wire or transfer money to a new account. These kind of emails are quite sophisticated and require you to be vigilant.

Try to confirm the sender’s identity before replying to email requests and before opening attachments or clicking on links, even if they appear to come from a legitimate source.

Below is an example of a fraudulent email request:

Your payment has been declined!
Your invoice (100421) with Office 365 Service is due.
To make a payment, please log in with your email address and password at
Once logged in please click select the Make a Payment icon in the Billing Tab. You may complete payment by Credit Card or Paypal on this page.

Once paid no further action is needed and your account will remain active.
We thank you for your continued business and assistance in helping us to get this resolved.
Feel free to contact us if you have any questions, comments, or concerns.


3.2 Attachments

Please follow these rules strictly:

  • *NEVER* open an attachment that you did not expect.
  • *NEVER* be curious to see what is in an attachment.
  • *NEVER* open an attachment if there is some other way for the info to be sent e.g. Screenshot of document.

If the rules above are followed then:

  • You can open an attachment if you have requested it and if sender is unable to take a screenshot.
  • You can open an attachment if you get a good explanation of its contents from the sender and they are unable to take a screenshot.

It is okay to save an attached eml file and open it with GEDIT as text, as it will not trigger any virus.

This does NOT mean that you can open attached files freely. As per the procedures above, you should NOT open any unknown or unexpected attachments without CONSIDERABLE thought.

But saving and then opening files with GEDIT to get an idea of their contents even if the view is mangled is okay. Although, there is little point in opening files like ZIP in gedit.

There is no way to determine if an attachment, even from someone you know, has not been infected and is therefore, dangerous.

The only protection is to rely on anti-virus/anti-malware e-mail filters and staff vigilance!

You can check the names and file types/extensions of attached files to spot any obviously strange or unexpected attachments, but this is not very effective. The filename of an attachment could be spoofed. An attacker could potentially exploit this by tricking the user in to opening an attachment of a different type to the one expected.

Attachments ending in .jar or any other unusual extensions shouldn’t be opened without SB's permission.

If there are a lot of attached files, don't assume they are all safe, make sure you asked for each of them.

4 Handling emails from unknown email addresses

Any sort of contact from an unknown email address must be ignored entirely, i.e. no response whatsoever from Support, as these emails could be from a fraudulent source. If the email is genuine, then the sender can surely contact their managers.

Support should keep in mind that hackers can send emails that look genuine, aiming to get private/confidential information and so should always stay alert when dealing with such emails.

5 Handling junk/spam email

In order to get better automatic spam email filtering please mark as many obviously spam emails as Junk, instead of just deleting them. Marking them will delete them so it takes not much longer to do.

  • DO NOT delete emails from Junk or Spam folder because they are used to identify future junk and spam emails.
  • Any email identified as junk should be marked as Junk so that they automatically go into the Junk folder. The spam filter in the mail server will use these emails in the Junk folder to decide what is moved into the spam folder.
  • You MUST ensure that all clearly junk/spam emails are marked as Junk/Spam in ALL email inboxes. In other words they MUST be moved to Junk/Spam folders and not left in our inboxes or other main folders.
  • Any emails which are not clearly junk/spam emails or are similar to genuine emails, but you know are spam/junk MUST be deleted i.e. NOT left in inbox NOR moved to Junk/Spam folders.

Failing the above we will have the following problems:

  • Real emails disappearing into junk/spam folders by our email server.
  • More junk/spam emails appearing in our inboxes than necessary.

The Junk email folder contains emails that have been manually marked as spam/junk whereas the "spam" email folder contains emails that have automatically been filtered out by the email server.

6 Avoid burdening email servers with excessive graphics

Support MUST install the "Auto Resize Image" addon in Thunderbird to reduce the size of images in emails resulting in a significant reduction in email size. See setting up auto resize image for details.

It reduces the burden on NEOSYS and NEOSYS client's email servers. This is especially important on long conversations about subjects that include many screenshots, since for just a simple one line reply, the email can consume many MB of space. It massively wastes the email server space and makes backups massive and generally a total waste of resources and time.

To be able to refer back to graphics in previous emails, add the SIZE column to your email program so that you can locate large emails with graphics rapidly without searching back one by one.

7 Client Communication Policies

7.1 Client Meeting Report Policy

After every Client meeting online or otherwise Support MUST send a Follow-Up email to the Client which is open and fully informative and not brief, stating the events during the meet and any action required by either or both parties. The email to the client must not shrink from discussing contentious issues due to a false sense of politeness or timidity to address issues face on. Obviously one should not be rude but it is not rude to address issues openly.(cc Client managers and NEOSYS Managers)

The follow-up email MUST be sent within 24 hours of completion of the meeting so that the points discussed during the meeting are fresh in all the meeting participants' minds. This means that reports for meetings on the day before the weekend MUST be sent on the SAME day.

In addition to above email if there is some information that needs to be shared internally and cannot be said in public to the client then send a Client Meeting report to Support.

Support must also update the Client Contact Record file in Google Drive immediately after sending out the follow-up email.

7.2 Follow Up of Support Issues

All voice/chat communication MUST also be followed up with an email confirming at least the gist of the communication to keep the whole support team updated on the issue.

If not possible to contact for any reason, then an email MUST be sent stating so and suggesting or requesting a time to connect.

cc Client managers (and/or BCC NEOSYS Managers) MAY be done if thought to be useful and/or appropriate.

7.3 Handling Contentious Emails from Clients

If emails requesting support become contentious, then voice, phone call or chat is REQUIRED to save time. However, client support via phone call should be done only on local or low-cost calls. High-cost international calls should not be used except in extreme circumstances.

If clients become deliberately combative or uncooperative then Support team is supposed to kick back a little but still emphasise the point. Perhaps it could be done better with a little ironic humour or a smiley. Avoid using !! while responding to contentious emails.

7.4 Apologising to clients for issues

We only need to apologise for major issues that are a) definitely our fault and b) we wish to indicate that there is some general issue in NEOSYS procedures and that we are dealing with it.

We do not want to invite bullying by some clients by seeming to lack confidence in our ability.

An explanation of the cause and possibly FP is of more value to the client, since an apology doesn’t really make any difference.

7.5 Discussing Pricing

All discussions about pricing must be done only in Sales inbox. If clients bring up pricing discussion in support emails, NEOSYS staff must respond to the client by starting a new thread in the Sales Inbox.

8 NEOSYS Support Response Time Policy

NEOSYS contracts, in the few cases where we have a written contract with the client, specifies that maximum response time is one business day generally and one business hour for complete stoppages of the system. Obviously we have to do far better than this in practice.

Support staff must inform clients of the progress of the issue if it is not resolved the same day but only if they contact at least 1 hour before office closing.

Deciding to wait on issues is fine (also refer to: Response to standard messages), but support MUST at least spend up to 5 minutes on issues to see if they can be handled quickly. Support MUST respond quickly to issues that can be handled quickly, otherwise the client suffers unnecessarily.

When an issue is fixed or a client request has been implemented in NEOSYS, Support must immediately let users know that the issue is fixed, so that clients can continue their work without any further delay. Quick and prompt responses from Support will gain the client's appreciation.

For routine requests for service where there is a reasonable expectation of delay by the client then no need to send rapid reply.

9 Default Browser for support staff

NEOSYS supports and develops for Firefox primarily but other browsers such as Chrome and Edge MUST also be tested working fine. Support team currently uses Firefox for all work related tasks in Ubuntu which includes testing, wiki work etc.

Also refer to Setting up Mozilla Firefox

10 Handling errors discovered by support staff

  1. Replicate the error on all browsers after ensuring that the browsers have script error notifications enabled.
  2. Check in all the wikis for a solution.
  3. If there is no immediate fix for the error, try to find and provide a temporary workaround, which the client can use until the error is fixed.
  4. If the error is new, do a thorough investigation (eg. check NEOSYS logs) and try to find a solution for the error.
  5. If you still cannot find a fix for the error, then escalate the issue to your manager with an explanation of the issue.
  6. Support MUST always provide full screenshots of all the steps required to replicate the error, as this will help identify the cause of the error much quicker.
  7. When sending screenshots of the issue to your manager, the top-left of the browser MUST be visible so that it is clear which browser, URL and database is used.
  8. Ensure that script errors (if any) are included in the screenshots. Include every detail available regarding the script error, for example: script name, line number etc.
  9. Support MUST report the error to support team by email to keep a record of all errors in NEOSYS. Support team looks good when errors are spotted and fixed pro actively. Do not ignore the error for any reason.
  10. When requesting the programmer to fix the issue, explain WHAT has to be fixed and HOW it has to be fixed. Refer to Handling request to create a new feature or modifying existing features
  11. The most important step when solving any problem is Future Prevention. eg. add the solution to wiki, so that support spends lesser time fixing the problem in future.

11 Handling browser script errors

If a script error is faced, support should take a full screenshot of the script error including the script name, line number, etc.

Include every detail available regarding the script error and also the steps to replicate it and escalate this to the programmer.

Chrome JavaScript Error Notifier extension shows all the details available in the initial script error message itself.

12 Various checks done by Support to investigate errors

A list of logs/reports that Support must look at, depending on the situation, to solve issues or investigate errors.

  1. Support inbox emails: Check old emails in Thunderbird. This is the quickest way to handle issues/errors that were handled recently.
  2. Logs/reports available in NEOSYS Menu
    • Request Log (Support -> RequestLog) - These logs can be checked to see what request were made and by which users etc., not as detailed as the xml logs mentioned under "Logs found on the server".
    • NEOSYS logs (Support -> Log) - Log of alerts sent out via email, e.g. backup email, login failure, etc.
    • What's New report (Help -> What's new in NEOSYS) - Contains a list of all the features added in NEOSYS
    • List of Database processes (Support -> List of Database Processes) - Status of processes windows running on the server.
    • List of documents in use (Support -> List of Documents in Use) - Currently used documents.
    • User details page (Help -> User Details) - To check logins and IPs and password reset details.
    • Version logs of files - The history of edits made to files in NEOSYS. This is available at the bottom of files in NEOSYS (e.g. Schedule file, Voucher file, etc.)
    • Usage Statistics (Support -> Usage Statistics) - Shows no. of requests made per user, per department, per database, per hour etc.
  3. Logs found on the server:
    • journalctl - Contains all systemd, kernal and journal logs of the server so use cleverly and filter as required
    • Xml logs - These logs can be checked to see what request were made and by which users etc. in detail.
    • Tmux screen 10 - Monitor for NEOSYS client processes sorted by total time spent and by processor time.
    • Tmux screen 11 - Similar to journalctl, but filtered by NEOSYS client requests.
    • Tmux screen 12 - Quick check if live/test is down. Displays the last time the svr file was updated.
  4. NAGIOS - Monitors the status of all hosts and services.

13 Handling Cheques from Clients

NEOSYS staff are not to accept deliveries from clients that might be cheques without prior instructions to accept the same. They can ask courier to wait a few minutes until NEOSYS accounts or management agrees but they may not be immediately available and probably will not agree anyway. If accounts or management is not immediate available, then cheque MUST not in any circumstances be accepted, otherwise client can cause problems in our accounts and we waste time visiting the bank to deposit.

NEOSYS payment terms do not accept cheques although clients are free to deposit cheques by themselves.

14 Client Password Policy

All client user passwords, including their initial one, are to be obtained via the user's email address using the password reminder/reset button on the login screen. (NEOSYS password policy)

NEOSYS staff should never know users passwords therefore NEOSYS will not obtain and grant user passwords. The reason for this is that in the event that users lose their passwords to other people who then login unauthorised then suspicion could fall on the NEOSYS staff who know their password.

All parties concerned, including client management, client users and NEOSYS support staff, benefit greatly from trusting that if something in a NEOSYS database is registered as having been done by a particular user then it was not in fact somehow done by NEOSYS support staff. Nothing should be done that would break such fundamental trust. To achieve this, NEOSYS support staff must never log in as particular users, never ask for users passwords and generally enforce the idea that all work logged as being done by users IS done by users.

Very limited amounts of work by NEOSYS support staff either in person or remotely using teamviewer is acceptable while a user is logged as long as the user login was performed by the user themselves, the user is present and the user specifically agrees with the work being done.

14.1 Support requests from ordinary client users

Any support requests concerning inability to obtain passwords should be forwarded to known skilled users on the client staff since this is the most efficient (not fastest) way to handle such issues.

14.2 Support requests from senior client management

Any support requests concerning inability to obtain passwords by senior client management users shall be handled directly by NEOSYS support staff in any way convenient to resolve the issue in the quickest possible time rather than the most efficient.

Bearing in mind that NEOSYS staff should never know user's passwords this will probably involve NEOSYS staff using the Password Reminder/Reset button to send a new password to the user.

14.3 User Defined Passwords

NEOSYS will provide user defined passwords in very special cases which must be pre-approved case by case by NEOSYS management. NEOSYS will not approve this due to the reasons mentioned here.

If the user login gets blocked due to multiple login failures and the user requests support team to reset the password to the user defined password again, support MUST delay the response to this request by at least 1 hour in order to force the user to be more careful when typing the password.

Currently permission for user defined password has only been granted to one NEOSYS client with several hundreds of databases.

15 Handling client issues and requests

All support issues must be dealt with through phone/email/chat. Support Staff can schedule client visits for User Training but should not schedule client visits solely for providing support for petty issues.

ALL Support staff should check all the previous day's inbound emails for reply flags once in the morning. All Support staff will therefore be held responsible for any unreplied inbound email.

Support MUST NOT waste time and delay support by investigating issues WITHOUT SUFFICIENT INFORMATION.

Support must NOT get involved in any discussion about any document that is not directly out of NEOSYS, so that Support is able to reproduce it from NEOSYS screenshots of screen options that the client used.

Support should look for similar issues when solving a particular problem to avoid similar issues in future. This saves the time and energy of Support as well as the Client.

When sending screenshots to clients, support team should economise on space by minimising to the minimum that will show the problem clearly. This is because not every user will be viewing their emails on large wide screens like NEOSYS support team. Browser windows reformat their contents to suit the width available so this is particularly effective in most NEOSYS screens.

Support team MUST be cautious while sending screenshots so that no private/unnecessary information is sent to Client. If you cannot avoid taking the screenshot without unnecessary information then you should hide it in the screenshot.

Support team MUST learn not to do silly support for people, because we have an OPEN SUPPORT policy, which some users WILL try to abuse based on either poor understanding or lack of respect. Either way support MUST learn to deal with abuse of privileges as it will save a lot of time, which could be spent on more important issues.

Sensitive issues related to security MUST be handled by one support person and checked by another support person.

15.1 Handling new emails in Support inbox

Support MUST spend up to 5 minutes on new emails and send a quick reply to the client, to acknowledge the request or give a quick solution in case it is a petty issue or has a documented solution in wiki.

Client issues/requests should be prioritized, interrupting existing work and not wait for one hour and be dealt with quickly.

For routine service requests where there is a reasonable expectation of delay by the client, Support need not send a rapid reply but must keep the email starred in Support inbox to indicate that it is pending or being worked on.

15.2 Handling starred emails in Support inbox

When an email is received in Support inbox,

  • if the email can be replied to immediately, then mark it as read after you have replied to the email.
  • if the issue cannot be resolved immediately, then the email MUST be starred so that support does not forget to work on it. Once the issue has been resolved, Support should send an email to Support inbox confirming that the issue is closed. Only then should the email be unstarred.

No issue should be silently dropped without being fully resolved.

15.3 Handling client-sensitive information in emails

Support should avoid including information that could be sensitive to clients e.g. screenshots of reports that should only be viewed by client's upper management.

This can be done simply by clever cropping of images or blurring out of information in cases where cropping is not possible.

Support MUST not delay response to any client by wasting time blurring or cropping out information that is not sensitive to clients, e.g. blurring out the URL and tabs in browsers etc.

15.4 Handling client call back requests

Clients who ask us to call them should be given our phone number and asked to call us unless there is some GOOD reason why we should make the effort and pay phone charges.

15.5 Handling login failure issues

Users often get login failure issues due to typing wrong password and they simply won't read and act according to the error message they get. In this case, Support must send the below email to the user.

Dear XYZ,

If you have trouble resetting password, please ask for assistance from your manager/IT Manager/Timesheet Administrator/NEOSYS-expert colleague.

NEOSYS Support

Local support users (TA or IT manager etc) have the LS key using which they can see the User Details page of all users. They should check all the information (usercode, registered email id, last login attempts etc) in the User Details page to find out what is the issue.

This procedure will reduce the endless mails sent back and forth to solve petty issues which could easily be solved by the client's local support.

15.6 Handling requests or demands for "URGENT" or "PRIORITY" support

Any request for prioritised action *without giving any reason for the prioritisation* should be disregarded and the request handled with normal priority. If a reason is given then you may at your discretion prioritise a response but there is no obligation to do so.

15.7 Handling users who login with other people's NEOSYS usercodes

This can cause a lot of confusion in both the client and NEOSYS support. It may also indicate that the correct NEOSYS monthly licensing fee is not being paid. There is no valid reason for anonymous logins or sharing logins between multiple users.

Therefore if NEOSYS support team get requests for support about using NEOSYS from users who are not registered properly in NEOSYS with a personally identifiable user code, name and email then the following email should be sent cc

No exception should be granted to clients without NEOSYS management approval.


Please note that in order to receive support from NEOSYS you must personally have an identifiable user code, name and email address registered in NEOSYS.

We can create a new user account for you with your management's approval. This may or may not have an impact on the NEOSYS monthly licensing fee depending on the agreement in force.

Please let us know what you would like us to do.

Best Regards,
NEOSYS Support

15.8 Handling support requests from expired users

If expired users call for any reason including not being able to login, they must not be given any support. They should only be told that their account is expired without any reason being offered because employers sometimes do not want any information at all being passed to expired users.

Instead, inform the client's senior management or other point of contact that the expired user has requested support.

15.9 Handling support request from senior management

Any support requests from senior client management users concerning report generations should be handled directly by NEOSYS support staff in any way convenient to resolve the issue in the quickest possible time rather than the most efficient.

Bear in mind that NEOSYS staff should not agree or offer to do client work. Support staff can advise senior management to contact a skilled user to help them with basic NEOSYS reporting. Support staff can also send screenshots of step by step procedure on how to take reports. Depending on the situation and reasons provided by senior management, support staff can at their discretion provide reports but after informing them that this is an exception and no more reports will be sent out as this is against NEOSYS procedures.

15.10 Handling requests that involve updating NEOSYS configuration files

Changes to any configuration file in NEOSYS MUST be performed only by NEOSYS support, because even the slightest misconfiguration of the system may cause unrecoverable errors and NEOSYS is responsible for support.

15.11 Handling emails with unrelated subject line

At times, clients forward old emails, with new issues, resulting in completely unrelated subject line. In such situations, support MUST follow the below steps to ensure that unrelated emails do not appear in the same conversation group when viewing emails in conversation mode:

  1. Right click the email -> HeaderToolsLite -> Edit full source
  2. Modify the text that appears after "Message-ID: <". (e.g. replace the first few characters with "xxxxxxxxx")
  3. Remove all texts that appear after "References:" and "In-Reply-To:" and click OK.
  4. Click Reply All on the modified email.
  5. Change the subject to a relevant one.
  6. Delete old unrelated content from the email body.

In the email reply, include a comment like "PS Please don't forward old emails for new issues, start a new email with a new subject so that emails can be traced easily."

Sometimes the client does not bother putting the correct subject line for new issues (e.g. blank subject, or "Error"). Then support should add a meaningful subject line in order to make the email easy to search for.

15.12 Handling emails with poor screenshots

Sometimes Thunderbird shows full sized screenshots in a compact format that is not easy to read. These can be resized to make them more legible. To do this, make the email editable by hitting the "Reply" button, then click and drag to resize the screenshot as desired.

If the screenshot sent by the user is genuinely small and hard to read, reply to the mail and request for a full size, clear screenshot.

15.13 Handling support-request emails sent to anywhere than

Client emails anywhere than MUST be ignored. This is because ALL support must be recorded in support inbox without exception so that the whole support team is aware of the issue and action taken. If client complains about the delay in support then they can be told this is because they used the wrong email address.

15.14 Handling users who do not act upon standard messages

When users do not bother to read and act on standard NEOSYS-generated messages and instead ask for help, Support staff MUST delay response time and thereafter send them an email which is the same as the message so they get the point that in future they should read the messages and handle issues themselves.

15.15 Handling Requests to do Client work

NEOSYS Support staff must not agree or offer to do work on behalf of the client.

This is because doing client work while logged in as NEOSYS breaks security rules. Support uses the EXODUS username which has unrestricted access, so when a user requests Support to do some work which they don’t have access to, and if Support agrees to do the work, the client has successfully defeated the security rules by accessing features that they are unauthorised to access.

If a client makes a false claim about an issue in NEOSYS, i.e. if Support finds out that there is no real issue, then direct the client in the right direction so that they find out their mistake by themselves. Support MUST NOT show/explain the problem to them in detail, since you are just doing their work for them by explaining the problem and this will encourage the client to contact support for every petty issue they face.

Client work also includes Handling issues with totals on reports.

15.15.1 Requests for colour and font changes

Support should not be spending lots of time on colour and font changes. Clients can make as many changes as they want until they are happy with a selection. Clients MUST send a screenshot of their required color/font settings (not sample screen/reports) for Support to copy and setup for all users. If Support sees them doing something bad or poor then give comments or better suggestions.

15.16 Handling Requests that require Approval from Higher Authority

The following is a list of user requests that must be handled by NEOSYS support staff only if they are approved by or come from a higher authority (manager/admin). The LIST is NOT a complete list so there may be other things which might require approval so use good judgement and/or ASK if in doubt.

If an unauthorized user sends one of these requests to support staff, support staff must immediately instruct the user to get the request approved by the higher authority.

15.16.1 Handling Requests from people impersonating an Authorised person

Clients may impersonate an authorised person by using their email address or signature when they are told that the request must come from or be approved by the authorised person. Support must use their judgement to deal with such requests.

If it is a simple request such as adding a new user or expiring one, Support can go ahead with the request.

If it is a request with risk involved such as providing remote access or granting high-level authorisation, Support must then contact the authorised person and let them know that their approval for the request has been received and are proceeding with the request.

15.17 Handling User Requests to add an IP or range of IPs to access NEOSYS

Support staff must identify if the IP or range of IPs is for http or https access. Sensitive issues related to security MUST be handled by one support person and checked by another support person.

15.17.1 For HTTP access

Support staff can add local IP or range of local IPs when requested by the client. Top management approval is not needed to add local IP numbers. Listed below are the IP address ranges reserved for local network. – – –

15.17.2 For HTTPS access

Any request for https access from any IP address or range of IP addresses (eg. 123.456.* or just *), or in other words any use of an asterisk in the IP restrictions, MUST have TOP management i.e. the company's decision makers approval. The Staff and their Managers are not the best decision makers in this affair because they usually ignore the risks and it is not really their decision. Security threats like access of data by unauthorized persons or ex-employees, malicious hacking attempts etc can be triggered if access from any IP is enabled. It is completely pointless to inform the staff who want the access about these risks because only their top managers could really decide that this is NOT going to be allowed. Hence the Top Management MUST be asked for approvals and at the same time WARN them about the security risks/threats behind the no IP restrictions. For clients with static IP

Any request to add a specific IP address to the list of allowed IP addresses MUST have management approval. For clients with dynamic IP

For clients with dynamic IP, support MUST NOT add their public IP to the allowed list as this will encourage the client to again request for access from new IP numbers every time their public IP changes. Instead, support MUST force the client to either get a static IP, install VPN or get the Top Management i.e. the company's decision maker's approval to enable access from any IP after explaining the security risks in doing so, as mentioned above.

Support MUST also mention that installation of VPN by the Company is the industry standard way of providing access to mobile staff (i.e. those on dynamic IP numbers from home or traveling) to corporate software assets like NEOSYS IN A SECURE MANNER. Installation of VPN is to be done by their own IT support. Refer to Using VPN to enable secure access from outside the office

Sample Email addressed to Top Management:

Dear <XXXXX>,
I do not recommend allowing access from all IPs because security threats like access of data by unauthorized persons or ex-employees, malicious hacking attempts etc. can be triggered if access from any IP is enabled.

I strongly recommend that you keep IP restrictions for <XXXXXX> dataset.
If you want to provide access to mobile staff (i.e. those on dynamic IP numbers from home or traveling) to corporate software assets like NEOSYS IN A SECURE MANNER, then installation of VPN is the industry standard of achieving this. Installation of VPN is to be done by your own IT support. 
If you still wish to allow access from all IPs, kindly confirm that you acknowledge the security threats of doing so. 

15.18 Handling repeated request to allow users to access from all IPs

Sensitive issues related to security MUST be handled by one support person and checked by another support person.

If the client wants temporary access from outside for some staff twice in say a six months period then support should send the below email. The real reason is because we don't have the time to be doing this on a regular basis. If at all the client asks why we no longer support the provision of temporary outside access then we can say this is because of the frequency of such requests.

Dear XXX

We have given you temporary outside access this time, as requested. Please note that we can no longer support the provision of temporary outside access. So in the future, you will have to choose between either permanent or no outside access. Alternatively, you can ask your management to install a VPN (which is the industry standard of achieving outside access to a corporate asset in a secure manner), so that you can log in to NEOSYS from outside.

15.19 Handling requests to create a new feature or modifying existing features

Many issues are small and not important but can still be considered for development because they may be easy and neatly added to NEOSYS.

The aim here is to avoid development on hard issues for little benefit, or little issues that make NEOSYS more complex for little benefit.

When a client requests to create a new feature or modify an existing feature, a workaround must be given to the user, which is either a permanent solution, for example if the issue is a rare case and not commonly faced by other clients (and the workaround is acceptable to the client), or a temporary solution until some better solution is discovered or can be developed.

If only a workaround can be provided, use the standard template email for "Not possible to Implement the new feature immediately".

Support MUST check all options on all pages to look for any already existing solution or workaround to the problem before emailing the programmer.

Any request to create a new feature or modify an existing feature MUST be discussed with other clients before forwarding it to the programmer because the other clients might not be comfortable with the change as it may not be in accordance with their workflow. If other clients agree to the proposed change then support should go ahead and request the programmer to implement it.

Therefore before escalating a request to the programmer to modify a feature in NEOSYS, the approval for the same from other clients must be taken into account.

Any request to fix or modify a feature in NEOSYS must be accompanied with good reason and some basic considerations, so that the programmer knows what level of priority it can be dealt with.

When escalating the request to the programmer, support MUST avoid using "Is it possible..?" because the obvious answer to that is "Anything is possible" and because this question is only a way to avoid doing the real work of deciding whether the new feature/modification should be implemented.

15.20 Handling requests to add more fields to List of Invoices reports

Many users may ask for the List of Invoices report to be expanded to show a zillion other things, but this makes it NOT a list of invoices. Therefore other break-downs MUST be obtained from other reports in NEOSYS.

15.21 Updating Clients about unresolved issues

Support should proactively inform clients if an issue is not solved within the same day it was raised, after judging the urgency of the issue and the time it was raised. An email to the client who raised the issue, before the end of each day, is a best practice that keeps the client updated and other support staff too. This email should be sent regardless of the degree to which the issue has been resolved or if the issue is unresolved. If the issue is unresolved, the email should explain why and also explain the cause of delay.

15.22 Handling new USER creation

15.22.1 Get Approval

Support staff should create new USERS for clients ONLY when requested by an authorised person. If the authorised person is unavailable, for example on leave, then get approval from someone who is in the backup mail list.

Ideally only people who are users in NEOSYS and have authority over some task can grant or request authority to do that task for other NEOSYS users. However, if this is not the case and the requesting person has some seniority in the company (but is either not a NEOSYS user, or is not actually currently authorised to perform the task themselves) you may decide that it is not wise to proceed without some confirmation. In such a case be very respectful of their position while rejecting any request perhaps stating something like:

"Currently we have instructions to take requests concerning authorisation only from xxx, yyy and zzz. Please could this request be confirmed by one of them?" Rewrite this judiciously to suit the occasion.

Consider that different sections of a company may have different chain of commands. For example one should not assume that a Sales Director has authority over Finance unless there is firm evidence. If there is any doubt consult NEOSYS Support Managers.

Support MUST NOT directly contact the authorised person asking for approval/confirmation because that is client work.

In case the client impersonates an authorised person to get a new user request approved, Support may go ahead with the request since it is not support's job to judge the authenticity of an email that appears to be from an authorised person. If the request is to create a user in a top level department, then you may choose to include other top department users/managers in your email so they are aware of the new user created.

Clients should not be discouraged to create new users. Clients are billed as per user usage which is reviewed periodically. Over time old USERS are replaced with new USERS.

15.22.2 Creating User


New user requirements :-

  • Full name - (like John Smith and not generic name like Copy Writer)
  • Email address - (like and not generic address like
  • Group level / User with similar authorisation

The USER code is the first name of a user.

1. Support MUST only create NEOSYS accounts with real names and email addresses WITH NO EXCEPTIONS unless agreed by NEOSYS management.

It is acceptable, although inefficient, for one person to have multiple user accounts either concurrently or sequentially, but the opposite MUST never occur. One NEOSYS user code/account MUST never have more than one real person associated with it neither concurrently nor sequentially. In order to maintain efficiency, various fleeting temptations to cut corners and break the ONE TO ONE link between NEOSYS user accounts and real people MUST be resisted. These principles remain mandatory even when pressure is exerted by people, even senior management, who may not appreciate the issues involved. The fact that NEOSYS support does not know for certain who is the real person using a NEOSYS account does not change these principles.

2. Support MUST not create GENERIC user codes like AUDITOR or MANAGEMENT (even to grant special access to such users like read-only access) as this breaks all security rules. Do not re-use user codes. Always create NEW user codes for NEW users.

3. Support MUST not create or modify any usable NEOSYS account that is or has been used by more than one user.

4. Support is responsible to maintain the system in good working order and not knowing who is really doing the work in the system can make support harder.

5. Support MUST not collude with clients to by-pass the principles. If asked to do so Support MUST refuse to create or update such accounts.

6. Do not hand over user codes from one person to another in a mistaken attempt to represent a hand over to a replacement. EXPIRE THE OLD USER CODE/ACCOUNT AND CREATE A NEW USER CODE/ACCOUNT.

Sensitive issues related to security MUST be handled by one support person and checked by another support person.

7. Support team MUST NOT discuss billings with clients unless authorised to do so. Also see Discussing Pricing

8. Support team MUST NOT proceed with creating new users until the group level or existing user with similar authorisation has been clearly provided by the client, otherwise the new user may end up with more than the required authorisation, which can lead to problems in future.

15.22.3 After Creating New User

Support MUST send an email to the person who requested the creation of new user, confirming that the new user has been created along with a screenshot of that part of the authorisation table where the new user was created so that the new user's user code and email id is visible. This is done so that in case there is some error in the user code or email id, it is easily visible in the screenshot and also so that the person who requested the creation of the new user is informed about the user code of the new user.

15.23 Handling letterhead change requests

Support staff should reject any requests that require the letterhead to be setup on the TESTING dataset before it is setup in the MAIN dataset. This is to reduce double work for support staff and to ensure that clients have a clear understanding of their requirements and also send the correct logo image. The MAIN dataset can be copied to the TEST dataset for any kind of testing.

See How to change letterhead

15.24 Handling error messages

Important: Before Attempting to resolve client issues, please ensure that we have secure access to the NEOSYS server.

  1. The very first step is understanding client problem. Ask questions to the client until you CLEARLY understand the problem.
  2. If the error is familiar and does not require a screenshot, resolve the problem immediately.
  3. If the error is unfamiliar and/or requires a screenshot and the user has not sent a screenshot, IMMEDIATELY use existing email template to ask the user to send a screenshot of the problem, along with the options used (basically you need to know HOW to replicate the error and the screenshot MUST show WHAT the error is).
  4. If the user says "nothing happens, so no screenshot of the error", then IMMEDIATELY request for screenshots again with the exact steps to reproduce the problem using mouse and keyboard.
  5. Support team MUST NOT provide support without a screenshot, otherwise the client will not pay attention to support team in future and ignore requests for screenshots.
  6. Upon receipt of the error and steps to reproduce the error, follow the steps and reproduce the error. Also refer to Addressing Browser related issues
  7. If the issue is unknown or you don’t understand it clearly, with the users acknowledgement use remote support to gain access to the users desktop to view how to replicate the error.
  8. Replicate the error on all browsers after ensuring that the browsers have script error notifications enabled.
  9. Check in all the wikis for a solution.
  10. If there is no immediate fix for the error, try to find and provide a temporary workaround, which the client can use until the error is fixed.
  11. If the error is new, do a thorough investigation (eg. check NEOSYS logs) and try to find a solution for the error.
  12. If you still cannot find a fix for the error, then escalate the issue to your manager with an explanation of the issue.
  13. Support MUST always provide full screenshots of all the steps required to replicate the error, as this will help identify the cause of the error much quicker.
  14. When sending screenshots of the issue to your manager, the top-left of the browser MUST be visible so that it is clear which browser, URL and database is used.
  15. Ensure that script errors (if any) are included in the screenshots. Include every detail available regarding the script error, for example: script name, line number etc.
  16. Support MUST report the error to support team by email to keep a record of all errors in NEOSYS. Support team looks good when errors are spotted and fixed pro actively. Do not ignore the error for any reason.
  17. When requesting the programmer to fix the issue, explain WHAT has to be fixed and HOW it has to be fixed. Refer to Handling request to create a new feature or modifying existing features
  18. The most important step when solving any problem is Future Prevention. eg. add the solution to wiki, so that support spends lesser time fixing the problem in future.

15.24.1 Understanding Internal error messages

Internal errors messages appear in red on screen and an email which is sent to support with more details. (Example below)


The "ERROR NO:" line is comprised of the error number (B16), the program (MARGIN_BASE) and the line number (1). Sometimes the line number is wrong, refer to section "Misleading line numbers in error messages" below for more info.

The "STACK:" line lists the "parent" calling programs "SYSMSG,LISTEN" used to trace how and where the error originates.

The "DATA:" is a string of characters that is used to recreate the options used by the client in order to replicate the error message. See how to replicate the error with the options used, using internal error email

15.25 Addressing Browser related issues

When resolving random browsing issues that seem to be on one user computer only, support MUST send the below email asking the user to check if the same issue occurs on other user computers. Rapidly convincing the user that the problem is only on their computer gains their willingness to sort the problem out at their end, using IT people if necessary and available.

Handling random issues that appear to be on one computer is very very common and it is important to deal with it effectively, not requiring stages of "denial" by the users until they accept something has to be done at their end, and not by NEOSYS. Speeding up this process gains the confidence and appreciation of the users.

Hi xxxx

Is this error happening only on your computer? If that is the case, it may be due to an issue in your browser cache. Please clear your browser cache with assistance from your IT team if required. Then restart the browser and try again.

If clearing browser cache does not fix the issue, I recommend a full browser reset to ensure that everything works fine.

Follow these instructions for clearing browser cache and resetting browser:

Please let us know if you face the issue again.

Also refer to Handling Browser related issues

15.26 Addressing Technical support emails

In the case of technical support issues, address emails to the IT person and cc the complete group of recipients of backup emails and other NEOSYS alert emails. This allows both NEOSYS and client IT staff to take credit for resolving issues that NEOSYS raises instead of working in the background unacknowledged.

Technical support issues include backup failure, server failure, missing alert email, server connectivity issues and port forwarding issues and many other issues.

For technical issues like browser configuration, clear cache, etc. support must send the user a link to the appropriate wiki article to help the user fix the problem. In some cases the user may be helpless and unable to follow the steps to fix the problem. In such cases, support MUST NOT waste time trying to help the user fix the problem, instead support MUST ask the user to get help from the IT person.

15.27 Acceptable report format when handling issues in NEOSYS reports

NEOSYS Support must only resolve issues in NEOSYS output first. This is because only NEOSYS outputs can be trusted and user versions in Excel or PDF could be copied wrongly or edited by the user.

In case users send reports in excel or other formats, get them to send the original NEOSYS HTML report as an attachment or copy-pasted in email.

15.28 Handling requests to create new charts or control accounts

Refer here

15.29 Handling issues with totals on reports

If a client has a problem with any total output by NEOSYS software then NEOSYS support will advise them which other NEOSYS report or reports provide a complete breakdown of the total (if necessary, to individual transactions) and ask the client to locate any offending transactions themselves.

NEOSYS support staff will handle any issues where the total on the breakdown report does not add up to the total on the summary report.

Reconciling totals can be hard if there are many transactions involved. Regardless of how hard it may be, reconciliation is an operational task for users not for support staff since NEOSYS support staff will not get involved in understanding client transactions or data.

15.29.1 Trial Balance and Financial Statements

NEOSYS support staff do not have to prove or trace any figures in NEOSYS Trial Balance Reports or any financial reports. If a figure is stated to be wrong by the user, then NEOSYS support staff should ask for proof or say NEOSYS is confident that the figures are correct unless proved otherwise.

NEOSYS support staff should point out reports in NEOSYS which will support the figures in question but not actually run the reports. Support staff can suggest the users to refer to detailed ledger accounts to prove balances.

16 Using VPN to enable secure access from outside the office

There are two ways in which a user can use VPN to access NEOSYS:

  • User connects to their office router and makes the PC act like it is on the office LAN.
  • User connects to a VPN service that provides a static IP number and can therefore be authorised by NEOSYS to login.

If the client intends to use VPN to connect to their office router and make the PC act like it is on the office LAN, then it depends on what VPN protocols the client's office router supports.

The alternative is to use a paid VPN service that provides a static IP number. Getting a dynamic IP number on VPN is very cheap and there are many suppliers, but getting a static IP number on VPN services seems to be more expensive.

Internally in NEOSYS we use PFSENSE routers which support OPENVPN which is extremely flexible.

17 Handling issues with Office PBX phones

Support should check their respective Office PBX phones every morning to find out if the phone is up and working. In case Support finds any issue with their phone, immediately fix it so that clients do not lose contact with the Support team via phone. Next send an email to Support inbox mentioning the fault, cause and solution for records/future prevention.

18 Running undocumented commands on Maintenance mode

Support Staff MUST NOT run undocumented commands on ***LIVE*** database. Some commands are not documented for a reason, it could be because the commands might give an undesired output or because there is no clarity on what else could be effected by the command.

Even if the command is tested in TESTING database and the output looks okay, support staff MUST get the programmer's approval before going ahead and running the command in LIVE database as there is no guaranty that the command is properly programmed and will do no damage.

19 Configuring Browsers to show Javascript errors in NEOSYS

NEOSYS Support MUST ensure the following Settings for browsers because if NEOSYS generates any javascript error message, the same would appear in the bottom left corner of a window, which in turn helps the programmer to fix the error. This must be done after every Factory Reset.

19.1 Chrome

Chrome Menu > More Tools > Extensions > Get More Extensions, search for Javascript Errors Notifier. Add the extension to Chrome.



19.2 Firefox

TODO: Find replacement for Firebug, below does not work Firebug add-on is used to NOTIFY about script errors because we have no other method to get any warning on screen but you should use the main firefox developer tools to investigate any errors as firebug is essentially replaced by built in developer tools.

For developer tools, go to Tools > Web Console

To enable notifications for script errors, download the add-on Firebug from here. When a Javascript error is encountered, the firebug icon will report the number of errors.

Set your firebug as per the second screen shot and select "Enable All Panels" as well, the tick will not appear like the other options but the option will get selected. If you miss out on any one of these steps, you will not be able to capture script errors.



20 Handling Browser related issues in NEOSYS

See NEOSYS browser requirements

Clients frequently ask Why NEOSYS doesn't support other browsers

To avoid browser errors, all new users must follow the steps given in Getting started with NEOSYS before logging in to NEOSYS for the first time.

To troubleshoot browser related errors see Troubleshooting Web Browsers

Pop-up blockers and any 3rd party toolbars must be deactivated/switched off or else certain pages and alert messages while using NEOSYS do not appear as a result of blocking from either the pop-up blocker or toolbars with built-in pop-up blockers.

NEOSYS support must ask users to Reset browser (See Reset browser) if they notice any user browsers which have pop-up blockers or 3rd party toolbars installed.

Also refer to Addressing Browser related issues

21 Handling NEOSYS Upgrade

See Upgrading NEOSYS

22 Handling auto-reply emails like Out of Office etc.

From 28th May 2017 version, emails sent out by the NEOSYS system contain headers that in effect request recipient email systems not to auto-reply for things like Out of Office. This is to reduce unnecessary chatter by silencing unnecessary automatic replies. There is no guarantee that recipient email systems will comply. The headers added are:

  • X-Auto-Response-Suppress: RN, NRN, OOF
  • Precedence: bulk

Support team should notify SB of any auto-responses that come despite their installation being patched.

In NEOSYS versions after 10th Jun 2017, emails sent by NEOSYS from the NEOSYS Help menu, i.e. manually triggered emails, do NOT indicate that OOF replies are not wanted, since if you are sending emails to people using NEOSYS, you will want to know if they are OOF.

23 Using Support Tools

23.1 Website Live Support

TODO: Find a replacement live support software, below software is not in use. is equipped with a Live Support software and clients can visit the website, click on this link and chat with any of our support staff, without the need for any installation. The client has to fill in their name and enter their questions to connect to an available support personnel. During non-working hours, the Live Support icon on the website automatically displays "offline".

NEOSYS Support personnel who are authorised to provide such support, need to login to Live helper chat in Firefox using the link given below:

Support personnel should enter the account details as provided by their Manager.

Enable notifications for Live helper chat so that whenever there is a visitor trying to contact Support team, the Support personnel will get the notifications on his screen.

Set the Live helper chat login page as your home page in Firefox and this page must be kept open for the whole duration of working hours.

Support must always be alert and immediately reply to messages from visitors.

Use the link below to enable notifications:

After setting up Live helper chat if you sign in to a new profile in Firefox, you might have to re enable the notifications after your Firefox is synced to the new profile.

23.2 Teamviewer

Since Teamviewer allows no restriction on access once a fixed pass is installed, Support must not install fixed pass on teamviewer however convenient it might be.


Running teamviewer live from a web link is fine because it does not allow installation of a permanent password

For certain tasks that require temporary install of Teamviewer on the client servers (e.g. upgrading Cygwin remotely), use Teamviewer 7 on the server as well as Support staff computer. Contact NEOSYS IT for commercial license of Teamviewer 7. Teamviewer MUST be uninstalled after usage, otherwise it creates an additional unnecessary security risk.

To support client users who use the latest version of Teamviewer, support staff must also install the latest Teamviewer version available alongside Teamviewer 7.

24 Documenting Processes in Wiki

NEOSYS Support staff must be in continual learning mode. This is mandatory for support staff and is not an option. Support must read, learn and understand everything in the support emails and ask questions if they don't understand. This understanding must be transferred into wiki in the form of new articles and improvements to existing articles.

For all articles related to formatting and editing in Wiki, see Documenting NEOSYS systems

24.1 Avoiding duplication of text in wiki

Duplication of text in wiki is to be avoided almost at any cost. Duplication has the problem that when one copy is changed or improved in future then it is highly likely the editor will fail to update the other copy or copies and wiki will over time become an inconsistent mess.

There are several ways to avoid duplication:

  1. Two or more procedures which have significant areas of duplication can be rewritten as a single procedure with alternatives in the middle of the procedure
  2. Wiki Templates- Templates reproduce the same text in all places and editing one place edits all places. See How to create templates in wiki
  3. Wiki links- Only put the text in one place and put links to that in all the other places that it is appropriate.
  4. Place a note in all copies something to the effect that "This is similar to x, y and z". This alerts any future editor of all other places in wiki that might also have to be updated.

Future modifications in one place may or may not be appropriate to other places. The editor must decide whether to change one or all places

24.2 Highlighting information in wiki

To highlight particular instructions or info in wiki do NOT invent new styles which are not the way the rest of wiki is done. Instead, follow the USUAL STYLE or open a DISCUSSION with any recommendations you have BEFORE USING THEM.

Instead of using various kinds of highlighting styles like bolding and words like "Note:", use the following words IN CAPITALS especially the word MUST.

The use of the following words IN CAPITALS indicates that you are using them in a special way with formally defined meaning as explained below. Use of the words in lower case indicates that you are using the word in an ordinary commonsense meaning.

  • MAY - means optional
  • SHOULD - means recommended and you need GOOD reason (not just any weak excuse) to not follow to follow this recommendation
  • MUST - mandatory

Only in the rare cases where the consequences of doing or not doing something are irreversible or take a lot of work to reverse then you can use your own additional highlighting methods, eg ALL CAPS, stars, color red etc.

24.2.1 Explain WHY

Any sentence which uses the word "MUST" in capitals, MUST be followed by a SPECIFIC REASON explaining exactly why is the instruction is mandatory; the reason MUST not be vague and non-specific meaning no more than "or bad things will happen".

WRONG way: You MUST also delete ads if deleting schedules.
WRONG way: You MUST also delete ads if deleting schedules otherwise it will cause problems in future.
CORRECT way: You MUST also delete ads if deleting schedules otherwise the deleted schedules' ads will still show in all media-diary like reports and screens

The Wrong way above gives a general reason "it will cause problems in future" which is vague and a reader may even go ahead and ignore "MUST" because there is no objective or proper side effect mentioned for not following the MUST statement. Basically he doesn't understand the point behind following a certain rule.

Whereas the Correct way gives a SPECIFIC reason for "deleting ads while deleting schedules", so reader will exactly know the trouble that will be caused if ads are not deleted. Therefore "SPECIFIC REASON" behind using the word MUST must be to the point and very informative.

24.2.2 Why explain WHY

The information contained in the WHY phrase is often extremely informative to the reader about things that you may otherwise not have considered saying.

The most valuable information is usually contained in the "WHY" of something. There is an apocryphal story of a company where managers could be fired if they gave instructions to their staff without providing explanation. In almost all cases it is better for the efficiency of a team of people that any instructions they follow contain the "WHY" of something. Only in few cases should staff be expected to follow instructions without being well or fully informed.

25 Email Retention Policy

25.1 Generally

Emails are retained permanently to allow old issues to be discovered in email searches.

25.2 Account:

Only the last 365 days of emails to are kept in general to reduce the burden on servers and clients due to the heavy number of emails.

For the backups/neosys folder, only 31 days is kept due to the very high numbers of emails ~250/day.

Deletions are configured in and done by a thunderbird client in NEOSYS IT so may not be continuous.

26 Use of personal email addresses by NEOSYS support staff

NEOSYS support staff MUST NOT use any personal email addresses for NEOSYS business.

The addresses that are created by support staff for themselves on joining are also considered personal email addresses and must not be used for NEOSYS business. These email addresses might be linked to NEOSYS wiki accounts but that doesn't matter because wiki is not confidential.

27 Accessing NEOSYS accounts on personal devices

NEOSYS staff MUST NOT install NEOSYS accounts on skype/nextcloud/gmail (or any other external tool) on their personal devices without written permission from NEOSYS management

28 Support Staff work-in-progress documents/files

Support Staff must not save working files hidden on their computer. Work that is not visible is not work. Support work should not be done privately and should be shared to all.

ALL personal working files however trivial MUST be stored in Nextcloud and MUST NOT be stored anywhere in personal computer (My Documents/Desktop etc.)

The personal encrypted pass file MUST be stored somewhere in personal folder under Nextcloud/support. This is because if there is a loss of OS/Computer, it should not lead to loss of access as all the passwords saved in the file will be lost.

29 Handling CLIENT/NEOSYS Servers

NEOSYS support staff must exercise extreme caution when working on CLIENT and NEOSYS servers. Do not risk making changes without due care and attention to the fact that the consequences of errors can be serious on working production servers.

30 Handling "List of Open Ports" reports

This email comes to NEOSYS support team once a day showing only those client's servers which appear to have changed what TCP ports are open to the internet since yesterday. It will also come once a week showing all clients servers open ports.

NEOSYS support team should work patiently with client IT staff, over time if necessary, to close all ports that are not absolutely mandatory to be open.

Clients with highly skilled IT staff may have a variety of ports open to various non-NEOSYS servers inside their organisation. In this case, NEOSYS plays little or no role other than getting their confirmation of exactly what ports are acceptable. Any new ports that appear over time should be handled in the same way.

For clients without such staff, NEOSYS is their only real line of defence and since NEOSYS requested opening some ports, we should get all other ports closed by patiently following up until action is taken. Involving management may be the only way to get IT to act.

High end port numbers (e.g. 49667) may represent transient outbound connections from users. Therefore for such port numbers, support team should contact the client only if the port remains open on the following working day.

In particular, port 80 and 443 controlling internal or external routers should be closed. It is NOT acceptable except in HIGH IT EXPERTISE environments that critical routers should be exposed to the internet and they MUST NOT be accessible from the internet because routers that do not have their software updated can be hacked using known defects. Even updated routers can be hacked. Making it easy for client IT staff to access the router configuration from outside is NOT a good enough excuse to break this rule. Professional IT does not allow access to critical routers from the internet.

Likewise, any port 80 (unencrypted web access) and port 3389 (RDP remote desktop) open to the NEOSYS server MUST be closed otherwise logins can be monitored and there is no way to guarantee server security.

Port 23 (Telnet) is an insecure port because it is unencrypted and should never be open for usage. This is standard practice and well known by any network professional. Since the port is unencrypted, attackers can listen in, watch for credentials, inject commands via man-in-the-middle attacks and ultimately perform Remote Code Executions (RCE).

If a port is definitely required and properly approved to be open by client IT support, please let NEOSYS IT (SB) know and it will be put in the "Authorised" column so that ports in the "Questionable" column are all pending action.

The report does not attempt to detect UDP ports since UDP ports can receive information from the internet without responding in any way so there is no way to detect them reliably.

Green color shows ports that have opened since the last report run. Open ports can sometimes not be detected accurately so a port may appear to disappear in one report and reappear in the next report.

30.1 Why should HTTP port 80 not be open on my router?

It is not advisable to expose any HTTP server for any private service on your computer network or router because HTTP is unencrypted and this means that all information regarding that service, including passwords, can be observed by any malware on your LAN and internet connection. This information can then be used to install horrible software on your internal PCs.

What to do?

Use https for any internal services - and advisably on a non-standard port, not the standard https port of 443.

For example, NEOSYS service is exposed as HTTPS (not HTTP) usually on port 4430 - not the standard https port of 443.

Commercial hacking is getting really common with things like FIREBALL and CRYPTOLOCKER causing a lot of damage.

It is advisable to take basic precautions pro-actively before any attack exposes weaknesses.

31 Handling Nagios Client Monitoring system

NEOSYS support staff on duty MUST follow the procedures outlined below in case the Firefox "imoin" add-on shows critical or warning messages for any service. Failure to schedule appropriate downtime will lead to REDUNDANT EMAIL ALERTS from Nagios every hour.

Any alert on the Firefox "imoin" add-on means that there is an issue that has not been attended to properly, and "attended to" does not always mean solved. Support staff MUST solve the problem immediately if possible.

If it is not possible to solve the problem immediately, then downtime/acknowledge the service and add a comment on the Nagios alert, explaining the problem briefly.

Support should check Nagios frequently during the day to look for any new alerts so that issues are fixed as soon as possible.

  • Nagios is required to be checked first thing in the morning and any critical or warning messages need to be dealt with to resolve the same at the earliest.
  • Some of the messages could be related to backup failures and the usual procedure as stated in Handling failure and warning messages on nightly backup alerts needs to be followed. In case the backup issue isn't resolved by 9:30 am, the Nagios service needs to be downtimed with an appropriate comment for a minimum of 2 hours and maximum until 1 am next day if the issue cannot be solved.
  • In case of "Backup not changed" warning status which occurs if the client has not interchanged the USB before 12 noon on that day, no action is required from the support staff and a downtime with a comment like "Backup media not changed - Emailed client" needs to be scheduled until 1 am next day.
  • In case any HTTPS, SSH, PING service or Host is down, immediate action is required and the relevant IT people at the client side needs to be contacted to get this resolved. A downtime of 2 hours with a comment like "Service/host down - Emailed client" is required to be scheduled with further intervals of 2 hours in case this is not resolved. Support staff shouldn't schedule downtime till 1 am next day, just to get rid of the alerts for the day. Proactive follow up with the client is required to get this resolved before the business day - more so, if there is a weekend ahead.
  • In case the HTTPS, SSH, PING service or Host goes down during the day, a grace period of 10 minutes is given before the issue is reported to the client IT, in case there is any temporary internet connection issue at the client or along the internet route.
  • In case the HTTPS, SSH PING service or Host is down for more than 1 day, client IT should acknowledge the problem and give NEOSYS support staff an approximate time frame before which the issue will be resolved. Set an appropriate downtime with a descriptive comment for such events.
  • In case Host is down for more than 2 days and there is no progress with the fix from client IT, the client management should be notified about the seriousness of not having access to server and their acknowledgement is mandatory.

32 Handling lack of remote access to NEOSYS server located in client’s premises

If access to the NEOSYS server is lost then we must determine the root cause by:

  1. Checking if the server is UP and running
  2. If yes, please check internet connectivity on the server
  3. If there is connectivity, please check the router for connectivity issues

Sample Response:

Dear XYZ,

Please note that we have currently lost access to the NEOSYS server. The server seems to be down at the moment and it seems that 
NEOSYS processes are not running on the server.
Kindly check if the server is UP and running. If yes, please check internet connectivity on the server.
Do keep us posted on the server status so we can test connectivity from our side as well.

Best Regards,

33 New Router (Port Forwarding)

If you have changed your router then you may notice that external access to NEOSYS is unavailable.


Setup a permanent access for NEOSYS by reconfiguring the Router / Firewall for Port Forwarding from Router to the NEOSYS Server as follows:

  1. Port 19580 > 19580 for SSH
  2. Port 4430 > 4430 for HTTPS

You can see Set Up Port Forwarding to learn how to configure your Router.

To see how to test/ troubleshoot port forwarding settings, go to Troubleshooting Port Forwarding.

Sample Response:

Dear XYZ,

You are requested to kindly setup a permanent access for NEOSYS by reconfiguring the Router / Firewall for Port Forwarding from Router to 
the NEOSYS Server,i.e.  port 19580 for SSH and port 4430 for HTTPS.

Once this is complete, kindly send me an email to confirm the same so that we could test connectivity from our end as well.

Best Regards

34 Creating and Handling passwords

34.1 Creating a password

Passwords are generated from a pass phrase and it is important to create a very difficult to guess pass phrase.

Passwords made out of a pass phrase MUST be at least 10 characters since using initials results in a lot of i's and a's etc which reduces the effectiveness of the password and allows hacking via brute force guessing especially since windows doesnt slow down logins even if it sees thousands of password attempts.

For example, a good pass phrase would be: Today is a good day and it is the best time to go for a holiday

The password for this would be Tiagd&iitbt2g4ah

The important instructions for the above are:

  1. You have to take the first letter of each word and that makes your password (i.e. by using initials)
  2. Wherever any word starts with a capital, then you have to take first letter as a capital (eg. For Today you will take T)
  3. Replace and with &
  4. Replace to with 2
  5. Replace for with 4

34.2 Handling passwords

  1. Never send the actual password - always send the pass phrase
  2. Make sure that the password created out of the pass phrase is at least 10 characters long since using initials results in a lot of i's and a's etc which reduces the effectiveness of the password and allows hacking via brute force guessing especially since windows doesnt slow down logins even if it sees thousands of password attempts
  3. Pass phrases are never to be sent by email, whatever the case maybe.
  4. Pass phrases can be sent by chat - however they have to be broken down in two parts and sent separately over two different messengers or if you are using Gtalk then use the 'off the record' mode.
  5. Using SMS to send pass phrases is the best known way as of now.
  6. If you save the passwords on your system in an file then:
    • Ensure that you only store pass phrases in the excel file
    • Ensure that the excel file is encrypted with a master password

35 NEOSYS Maintenance Window

NEOSYS is available 24x7, unlike the old (AREV) NEOSYS where there was a 5 hour maintenance window from 1 am to 6 am daily.

The only disruption is at 03:21 am GMT mid-week, when the server reboots automatically only if required after Linux updates.

36 Using NEOSYS Terminology while communicating with Clients

NEOSYS support must communicate in correct language to clients on finance issues in order to ensure that our records exactly represent reality. Conversely NEOSYS must not use other terminology because it can cause considerable confusion and poor quality results. In case client is new and still in training, use client terminology optionally as long as

  1. It is only an addition to NEOSYS standard terminology
  2. Only if clear that it is client terminology by putting in brackets like this "Sales Invoices (called PI by you)", where "you" means the client you are talking to or you can put the client company name instead perhaps.

The objective is over time to avoid having the support team to have to know the terminology of the client. NEOSYS support team cannot possibly know and remember it for each client therefore the client MUST over time learn and use NEOSYS terminology. The initial period is one of relearning and translation for the client not for NEOSYS.

Many users operating NEOSYS finance module do not know proper financial procedures and may not appreciate how doing something in a wrong or unusual way now may not be correctable in the future.

NEOSYS staff must follow NEOSYS procedures only. If NEOSYS procedures need to be updated then this must be agreed in advance and not AFTER the fact.

37 Amending/Reposting Journal Entries

In certain exceptional cases, amending/reposting of journal entries is allowed for only one day to enable clients to present reports in an alternative manner.

It must be agreed with the client that reposting rights will be granted for only one day and NEOSYS Support will automatically remove it and check for CCB error thereafter.

This would be subject to NEOSYS requiring a written LETTER OF APPROVAL duly signed and stamped by the highest management of the company.

In case the client management decides to allow editing/reposting of journal entries, then follow the procedure mentioned in Reposting a Batch in Journal Entry

38 Removal of unauthorized third-party software on client servers

Rule: Any third party software that is discovered by NEOSYS support staff on client servers that has been installed without the agreement of NEOSYS should be uninstalled immediately on discovery.

However purposeful a software is, NEOSYS is contractually responsible for support and there are too many opportunities for poorly installed software to cause unpredictable damage to the NEOSYS database so NEOSYS has to have a clear and safe and simple policy to ensure the integrity of client data. Installing software without prior discussion with NEOSYS by itself indicates that insufficient care and consideration has been given to possible issues.

Having unauthorized third party software on the server can possibly lead to a backup failure. For example, LISTS file not available error.

Any software required by client IT for some purpose may only be installed after discussion and agreement from NEOSYS support staff concerning the configuration and operation of the software.

The NEOSYS Software Licence and Support agreement requires that where NEOSYS software is installed on client servers that a dedicated server is provided and dedicated implies that no other software may be installed without the agreement of NEOSYS support.

39 International v/s Indian English

There are some words which have completely different meanings in International and Indian English. NEOSYS Staff should follow International English only. Below are the examples of few of those words:

Word: Doubt

In the English language word "doubt" means to distrust an alleged fact on the basis of a reason, depending on the strength of the reason which may be anything from factual to feeling e.g "I have no reason to doubt him". This usage is followed worldwide.

Some people especially from Indian origin use "doubt" when they are unaware about a fact. e.g "I want to clear my doubts about this procedure" or "I have a doubt in this ..". This is incorrect. The word must be used when you do not agree on something on the basis of a reason and not when you do not have knowledge about it. e.g. "I doubt this script will complete in time".

40 New Employee Training Checklist

41 New Client Training Notes

42 General Office Procedures