Remote use and/or secondary offices

If you are at home or on vacation and want to do work in ServiceDesk (or within anything else that’s installed-on or is otherwise available from within your office desktop), it’s very easy.  Just setup an account (these are either inexpensive or free) with, or any similar service.  Then, within that account, setup your desktop to act as a host.  Once that’s done, you can be at any computer anywhere in the world that has internet access, and within about 60 seconds (via a rather simple login process) find yourself with power to remote-puppeteer your office desktop — with power and flair that’s virtually the same as if you were physically there.

It’s a truly terrific capability, and it’s hard for us to imagine why any owner or manager would not want to avail themselves of it.

Beyond that, you may have particular employees that wish to work from home.  If any such employee is also equipped with an office computer, that computer can be setup (under your same LogMeIn or similar account) to also act as a host, credentials setup for it, those credentials provided to the employee, then the employee can access that computer from anywhere, and do remote work.  If it’s a person that doesn’t otherwise have any physical presence at the office (and therefore there is no computer there assigned to him or her), it’s possible you might have a spare box that’s sitting around, and can be used for the purpose.

All the above is great, if your need for remote use does not extend beyond the kinds of circumstances described.  However, many businesses wish to accommodate remote use on a larger scale.  As a particular example, some businesses wish to setup with multiple offices (e.g., the main office, plus a satellite or two).  Some may just want to have multiple remote users, and without each requiring a dedicated “slave” box at the office (i.e., which they can remote-puppeteer via something like LogMeIn).  The remainder of this section will discuss the optimum strategy for achieving such a further purpose.

To start, let us state as a general principle: Just because multiple other persons are at one or more different locations (in particular, as compared to your main office), it does not follow they should be unable to work within the same program and data set — as if they were in the main office.

Regardless, the situation is at least more challenging than where everyone is working within the same premises.  It requires a more extended solution, which is our remaining topic here.

We will begin by contrasting the more typical, single-premises situation.

Where there is physical proximity of all direct workstations (i.e., same building or building complex), they will in almost every instance by configured to “talk” within one and the same Local-Area-Network (aka LAN).  This works great.  Communication across a LAN is easily configurable, and is super-fast.  Where all stations are in the same LAN, ServiceDesk setup is simple.  You can go thick-client or thin (generally we recommend thin).  To enhance your understanding, let’s briefly discuss each.

In the thick-client scenario, you have ServiceDesk installed at each station.  When you click on the icon to run it, your local processor (CPU) finds the program file on your own local drive, pulls its contents from there, loads the same into its operating memory, then proceeds to execute the program according to its prescriptions.  Much of this execution involves reading from and writing to data files that are contained on the particular computer you’ve setup to act as a “data server.”  This might be an ordinary PC.  It could be a Linux box.  It may or may not be additionally running ServiceDesk itself.  For the purpose described here, it is simply a “box” that holds the desired data in a set of files on its own hard drive.

The thin-client scenario is not very much different.  Here, you simply don’t have a local install.  Instead, when you click on the icon to run ServiceDesk, your local processor reaches to grab an instance of the program file (again, to load into itself) that, instead of being stored on your local drive, is instead stored on the very same machine that’s acting as your data server.  Just as in the thick-client scenario, that data server can be almost any kind of box (e.g., a plain PC, a Linux box or even a dedicated Windows server).

Hopefully, the above helps you form a good picture of a standard, within-LAN setup.  We need that picture to distinguish from what’s practical when you have multiple offices (or even just one or two remote users) that are not in close physical proximity.

In this latter case, you don’t have the same advantages as when within a LAN.  Quite obviously, your communication between distant offices cannot be through a LAN, because LANs only extend across more limited spaces.  It must instead be via the Wide-Area-Network (aka WAN) — which (and in case you did not know) is simply another title for the Internet.

In comparison to a LAN connection, WAN connections suffer many comparative debilities:

  1. ‍Even super-fast broadband connections (i.e., via WAN) are many times slower than communication via LAN;
  2. ‍WAN connections are more vulnerable to security compromise (i.e., someone tapping into the data flow and capturing information that might harm you or others); and
  3. WAN connections require more complex protocols to setup and maintain.  

Items 2 and 3 can be overcome by setting up what’s called a Virtual-Private-Network (aka VPN).   Essentially, it’s a way of configuring security and connection elements at both ends of a desired connection (i.e., from within Office1 and Office2) so that communications between them are as secure as in a LAN, and are individually as easy to setup and manage (this is aside from the very large complexity as involved in first setting up the VPN itself).

Unfortunately, a VPN does nothing for Item 1 above.  In other words, even with a VPN, the speed of a WAN-dependent connection remains many times slower, as compared to a LAN connection.

For many applications, this speed issue is not a problem.

Suppose, for example, you are locally running MS-Word, and you’re in an office that’s remote from the applicable data store.  When you open a document, the data that describes the document will be pulled from the data store, transported across the WAN, and placed into RAM on your local machine, where it will then be manipulated as you do your work.  There will be no need for ongoing communication, with the data store, as you work on the document.  The next need will arise only when you save the document, at which time your saved work will pass through the WAN, back to the data store, to there be saved.  Unless it’s a rather large document, the time as involved in these two movements will not be onerous.

Unlike MS-Word, ServiceDesk operation involves very frequent, repeated (indeed almost constant) back and forth access between the application and its data store (including a multitude of files that over time become rather large).  Because of this, if the processor that’s running ServiceDesk is in fact across-the-WAN from its data store, you will see ServiceDesk crawl.  It will be ugly.  It will be virtually unusable.  It is not practical.

So what’s the solution?

To be very specific, how can we make it so the particular processor that’s running ServiceDesk has no less than a LAN-intimate connection to its data-store, while still allowing some of its users to work in a remote office?

At first blush, it might seem it’s impossible to achieve LAN-intimacy, between a remote office where instances of ServiceDesk are evidently running, and a data-store that’s in fact at a distant location.

Did you notice our emphasis on the word “evidently?”

There’s a trick, and it involves a special thing “Server” versions of Windows are configured to do, that ordinary Windows versions are not.

You’re likely familiar with the fact ordinary Windows can be setup with multiple user logins, each with its own desktop that plays its own set of applications.  Of course, an ordinary Windows setup will only “play” one such user desktop at a time.

Though “Server” versions of Windows have some other differences, the most significant difference is they are not subject to this one-desktop-at-a-time limitation.  Indeed, a “Server” version of Windows can “play” many, many user desktops simultaneously.

Typically, of course, even a server version of Windows is direct-connected to but a single user interface (i.e., mouse, keyboard and monitor).  You might call this desktop the “standard” or “native” one.  The others are generally called “Virtual Desktops.”

So, where are the user interfaces for those multiple “Virtual Desktops?”

Essentially, any other computer interface can plug into any of a server’s virtual desktops by using a technology called “Remote Desktop” (aka RDP).  Remote Desktop is automatically a part of every modern Windows system.  If you’re on any such box and have the credentials to login to any virtual desktop as being played by any Windows server anywhere, all you need is to run your own computer’s Remote Desktop utility, put in the credentials, and inside of seconds you’ll be running that virtual desktop that’s “playing” on a server elsewhere — in spite of the fact that server may be located many thousands of miles distant.

And here’s what’s particularly great.

So long as that server is LAN-intimate with any data-store that an application within your own virtual desktop is running (e.g., ServiceDesk), the application will perform superbly.  Typically in these setups, indeed, the data-store is on the server itself — i.e., the same machine, which makes it even better than LAN-intimate.

So, that’s the trick.  Essentially, ServiceDesk runs on the server (in multiple instances upon multiple virtual desktops), with workers in your remote office remote-pupeteering it (indeed, not just it, but their entire desktop environments as well).  Indeed, they can do the same from their homes, or any location desired.  Plus, there is no need for an underlying (and complication-causing) VPN.  The RDP technology takes care of security.

How do you go about setting up this kind of configuration?

Surprisingly, it’s not difficult.  We have a number of users who’ve done it themselves.  We have others who’ve hired professionals.  There are a plethora of companies that will lease you such server capacity, online.  Even here at Rossware, we offer to provide such online server services for you.  Our service is called Rossware Server Solutions (RSS).

All in all, our purpose in this document has been to help you understand the general concepts.  We hope it has succeeded.