House-on-the-Hill Logo

IT Service Management (ITSM / ITIL)

Powerful, quick, simple, ticket logging software. Tailor the way you want to create tickets.

Computer Aided Facilities Management (CAFM)

Manage your whole property portfolio, jobs and keep your engineers on the road.

Customer Service Desk Management (CSM)

Help your team to provide quality customer support and use data driven decisions from reports and more.

FOI & SAR Case Management Software

Turn requests into fully audited cases that track Freedom of Information, Subject Access Requests, EIR, Discovery & more.

Enterprise Service Management (ESM)

Making our house your organisation's digital home
Pricing

Roadmap

To be a household name in helping organisations exceed customer expectations through
​⚡super-charged service delivery ⚡

About House-on-the-Hill

A small business running powerful service desk solutions

Customer Testimonials

Dont just take our word for it, see what our customers say

Blog

Keep up to date with all that we do at HotH

Customer Case Studies

Read how we helped businesses make our House, their Home

Contact House-on-the-Hill

Need help? Want a demo? Questions on our pricing? Get in touch, were ready to help

Careers

Interested in joining the HotH team?

Social Values

We are proud to support charities, fund-raising events and work experience programs
Migrating HotH - houseonthehill.com Product Documentation

Migrating HotH

This page outlines the technical steps required for the migration of a typical HotH installation between two machines. As with all system migrations, House-on-the-Hill Software advocates a controlled approach in which the new environment is proven to be working before the existing system is closed off.

It is assumed that the system comprises one box for the application. If there is a DMZ instance in use, please contact us.

There is extensive technical information available in our Technical Setup Guide and it is also recommended that you have checked any new hardware/Operating systems against the Installation Prerequisites and System Requirements.

It is simple to think of the migration as having 4 separate tasks:

  1. Moving the database.
  2. Moving the application.
  3. Moving the WebServer (if installed)
  4. Reconnecting clients.

Where possible we advise that the existing system be kept running as long as possible up to the final switch over so that it can provide a reference point and roll back option. Where possible, files/database should be copied rather than moved. Only when the new installation has been confirmed as working should the existing system be made unavailable.

If the migration is to be phased then we would advise moving the database first and ensuring everything works, then moving the applications.

This page does not cover the availability aspect of any migration, this has to be planned and handled as per individual considerations. In any plan however there has to be cessation of use of the current system, down time, and then a start-up of the new system.

Moving the Database (SQL)

    1. Backup the existing database.

Use MS SQL Server to create a full Database Backup ( .bak file) to transfer the SQL Server Database to the new Server. Please refer to your DBA if assistance is required with this step. Ensure that all use of the database has been stopped, i.e. Web and Windows access, Escalator, Email and KPI Services.

    1. Restoring the database on the new machine.

Restore the database to the new Server using the facilities within SQL Server. Please refer to your DBA if assistance is required with this step.

    1. Create a new HotH SQL Server User.

This is a vital step and omission will result in failure of the migration. Create a HotH SQL user on the new machine as per usual according to ‘Technical Setup Guide’ with the rights Public and db_owner. This must have a different name from the one already used as the SQL user on HotH – (which is usually ‘suppdesk’). For the purpose of this document assume the new sql user is called “hothtemp’

    1. Connect HotH Database tables to new User

The main problem when transferring databases between Servers is that the ownership of the HotH tables will change, as each SQL Server User, even if it has the same name, has a unique SID number. This means that ownership of the tables has to be temporarily moved to another owner, ( the new “hothtemp” owner) and then moved back.

To alter the owner of all tables in a SQL Server database using the following command in Query Analyser:

use DATABASE_NAME
exec sp_msforeachtable @command1=”print ‘?’ exec sp_changeobjectowner ‘?’,’USER'”

where DATABASE_NAME is the name of the database and USER is the user name of the new owner, “hothtemp”. There should be no errors after this query is executed but SQL will show warnings. After logging out and back into SQL Server the ownership of the tables for the HotH database should now show as the new temporary user. If not then repeat the step.

    1. Remove old user name.

Now that the database tables have a new owner remove all traces of the old SQL login. This may appear under Security –logins but need not appear there. It may also appear under Database – users.

    1. Recreate ‘suppdesk’ user.

To gain advantages of continuity the original SQL user ‘suppdesk’ should now be created (if your original SQL login was not ‘suppdesk’ then create the user that you originally used). Set the same password as was originally used which will save modifications to ini files later. Create this user as advised in the “Technical Setup Guide” making sure it has Public and db_owner rights on the database.

    1. Transfer ownership of tables back to ‘suppdesk’

Once the original user (‘usually ‘suppdesk’) has been recreated the ownership of the HotH tables should be transferred back to this owner using the same statement as previously described but with the new user name set as the ‘USER’. After logging out and back into SQL Server the ownership of the table for the HotH database should now show as the original SQL user that was recreated in step 6. If not, then repeat the step.

    1. Customisation of the Database.

If the HotH database has been modified by the customer in any way – such as the addition of stored procedures, triggers, and maintenance plans etc. then the migration of these areas remain the responsibility of the customer and are not covered in this page.

    1. Back-up procedures.

Please ensure that any backup procedures that are in place for the database are replicated after the migration.

Moving the Application

  1. Copy over the installation directory and all its sub-directories to the new server. If the application can be saved in the same directory structure as the original it can save changes later.
  2. The security properties of the suppdesk folder and subfolders on the new machine should be set to be the equivalent of that on the old machine (permissions/sharing).
  3. —-Tasks required after the database has been copied—-
  4. (Once the database has been copied.) Create the required ODBC DSN on the new machine to point at the new database location. Use the same name as per the old server. Test the Data Source with the ODBC . Note – if using a 64 bit machine ensure that the correct ODBC administrator is called from the run command %systemroot%\syswow64\odbcad32.exe or may show in the Administrator tools menu tree.
  5. (Once the database has been copied.) If any machine specific directories or names have been used in the setup of HotH these must be amended as appropriate for the new machine. Check any suppdesk.ini files ( or variations such as suppdeskwin, suppdeskescal, suppdeskmail ) and ensure that any directories specified in these files is still appropriate.
  6. Back-up procedures. Ensure that any backup procedures that are in place for the application are replicated after the migration.
  7. Any customisation of the Application carried out by the customer that may be affected by system migration must be considered and addressed by the customer.
  8. If you mail templates contain images then these will need to be modified so that they are referencing the image path on the new server location.

Recreating the WebServer

If there are any mappings/bindings that have been carried out to the WebServer outside of the normal HotH setup then these should be identified prior to the change and owners assigned to make the appropriate changes. e.g. Links from Intranet sites

Experience has shown that the web.config file must be deleted from the copied HotH installation directory before recreating the new HotH WebServer installation.

If the WebServer is part of the HotH installation and is also being moved then this will require a re-installation of HotH WebServer on the new machine as per the “Technical Setup Guide“.

When the HotH directories were copied the suppdesk.ini file that is used by the WebServer will also have been copied. This will need checking to ensure that there are no machine specific directories contained within it. If so these must be changed as appropriate. Once the WebServer is running it may be necessary to login and select Settings – WebServer. In this screen the settings for the URL’s of the WebServer (and KPI and Reports) are shown and should be maintained to match the new settings.

Attachments

As the attachments directory may be sited outside of the installation directory we recommend
testing of all HotH functions surrounding Attachments.

Reconnecting HotH Clients

On each client:
The short cut icon must now point to the new location. (Make sure that the Start-in parameters are changed as per the new machine). Ensure that you have tested one client successfully before moving any other clients. The ODBC must also be changed to point to the new database server. If all other things are correct then the sql user name should not need changing. If problems manifest with permissions on the location of the ini it may be worth amending the shortcuts to include the argument that forces the suppdesk.ini to be written and read from the user profile directory…

\\server\suppdesk\supdskcs.exe /i”%USERPROFILE%\suppdesk.ini”

Record Import Issues

If you find that it’s not possible to import more than 1000 records. Here follows an alternative to changing the AD query when doing an LDAP load.

As an alternative to changing the AD query default row number we can now make use of the fact that we support multiple scripts and break them up by alphabet. Set up each script as normal (tick the Sync box to make sure the auto-load happens each night) but in the filter line, include lines as shown below (one per script):

Script 1 – Names beginning with letter A*

(&(objectClass=User)(objectCategory=User)(cn=a*)(!userAccountControl:1.2.840.113556.1.4.803:=2))

Script 2 – Names beginning with letters B* through to H*

(&(objectClass=User)(objectCategory=User) (|(cn=b*)(cn=c*)(cn=d*)(cn=e*)(cn=f*)(cn=g*)(cn=h*)) (!userAccountControl:1.2.840.113556.1.4.803:=2) )

Script 3 – Names beginning with letters I* through to O*

(&(objectClass=User)(objectCategory=User) (|(cn=i*)(cn=j*)(cn=k*)(cn=l*)(cn=m*)(cn=n*)(cn=o*)) (!userAccountControl:1.2.840.113556.1.4.803:=2) )

Script 4 – Names beginning with letters P* through to Z*

(&(objectClass=User)(objectCategory=User) (|(cn=p*)(cn=q*)(cn=r*)(cn=s*)(cn=t*)(cn=u*)(cn=v*)(cn=w*)(cn=x*)(cn=y*)(cn=z*)) (!userAccountControl:1.2.840.113556.1.4.803:=2) )

Script 5 – Account names beginning with Numbers

(&(objectClass=User)(objectCategory=User)(|(cn=0*)(cn=1*)(cn=2*)(cn=3*)(cn=4*)(cn=5*)(cn=6*)(cn=7*)(cn=8*)(cn=9*)) (!userAccountControl:1.2.840.113556.1.4.803:=2) )

 

Still haven’t found what you’re looking for? Contact documentation@houseonthehill.com

Back to Top

Previous – Updating HotHNext – Test Environment Setup