Multiple office setup

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 straightforward. Just set up an account(these are either inexpensive or free) with LogMeIn.com, GoToMyPC.com, or any similar service. Then, within that account, set up 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 relatively 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 who 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 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 circumstances described. However, many businesses wish to accommodate remote use on a larger scale. For example, some companies wish to set up 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 mean 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 the physical proximity of all direct workstations (i.e., same building or building complex), they will, in almost every instance, be configured to “talk” within the same Local-Area-Network (aka LAN). This works great. Communication across a LAN is effortlessly configurable and 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, and then proceeds to execute the program according to its prescriptions. Much of this execution involves reading from and writing to data files on the computer you’ve set up 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 hard drive.

The thin-client scenario is similar. 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).

I hope Wide Area Network (aka WAN) — (and in case you did not know, 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 within a LAN. 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:

‍Even super-fast broadband connections (i.e., via WAN) are many times slower than communication via LAN; ‍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 ‍WAN connections require more complex protocols to setup and maintain. Items 2 and 3 can be overcome by setting up a Virtual-Private-Network (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 set up and manage (this is aside from the enormous 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 much slower than that of a LAN connection.

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

Suppose, for example, you are locally running MS Word and in an office that’s remote from the applicable data store. When you open a document, the data that describes it 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. You will not need ongoing communication with the data store as you work on the document. The following 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 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 many 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 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 involving a particular thing: “Server” versions of Windows are configured to do things that ordinary Windows versions are not.

You’re likely familiar with the fact that ordinary Windows can be set up with multiple user logins, each with a desktop that plays its own set of applications. Of course, an ordinary Windows setup will only “play” one 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”. The others are generally called “Virtual Desktops.”

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

Any other computer interface can plug into a server’s virtual desktops using “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 log in 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 and enter the credentials. Within seconds, you’ll be running that virtual desktop that’s “playing” on a server elsewhere — in spite of the fact that the server may be located many thousands of miles away.

And here’s what’s particularly significant.

So long as that server is LAN-intimate with any data store that an application within your virtual desktop runs (e.g., ServiceDesk), the application will perform superbly. Typically, in these setups, the data store is on the server itself — i.e., the same machine- making 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-puppeteering it (indeed, not just it, but their entire desktop environments as well). Indeed, they can do the same from their homes or any location they desire. 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 complicated. We have many 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 you such online server services. Our service is called Rossware Server Solutions (RSS).

Overall, our purpose in this document is to help you understand general concepts. We hope it has been successful.

If you want to get an idea of the costs, Rossware’s RSS pricing can be found here.