This is an excerpt from Section I in the main Manual’s Appendix.
If you are at home or on vacation and want to do work in ServiceDesk (or within anything else that’sinstalled-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 LogMeIn.com, GoToMyPC.com or any similar service. Then, withinthat account, setup your desktop to act as a host. Once that’s done, you can be at any computer anywhere inthe world that has internet access, and within about 60 seconds (via a rather simple login process) findyourself with power to remote-puppeteer your office desktop — with power and flair that’s virtually the same asif 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 wantto avail themselves of it.
Beyond that, you may have particular employees that wish to work from home. If any such employeeis also equipped with an office computer, that computer can be setup (under your same LogMeIn or similaraccount) to also act as a host, credentials setup for it, those credentials provided to the employee, then theemployee can access that computer from anywhere, and do remote work. If it’s a person that doesn’totherwise have any physical presence at the office (and therefore there is no computer there assigned to himor 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 circumstancesdescribed. However, many businesses wish to accommodate remote use on a larger scale. As a particularexample, 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 theoffice (i.e., which they can remote-puppeteer via something like LogMeIn). The remainder of this section willdiscuss 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 moredifferent locations (in particular, as compared to your main office), it does not follow they should be unable towork 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 samepremises. 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 (akaLAN). This works great. Communication across a LAN is easily configurable, and is super-fast. Where allstations are in the same LAN, ServiceDesk setup is simple. You can go thick-client or thin (generally werecommend 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 theicon to run it, your local processor (CPU) finds the program file on your own local drive, pulls its contents fromthere, loads the same into its operating memory, then proceeds to execute the program according to itsprescriptions. Much of this execution involves reading from and writing to data files that are contained on theparticular computer you’ve setup to act as a “data server.” This might be an ordinary PC. It could be a Linuxbox. It may or may not be additionally running ServiceDesk itself. For the purpose described here, it is simplya “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 theprogram file (again, to load into itself) that, instead of being stored on your local drive, is instead stored on thevery same machine that’s acting as your data server. Just as in the thick-client scenario, that data server canbe 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 thatpicture to distinguish from what’s practical when you have multiple offices (or even just one or two remoteusers) 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, yourcommunication between distant offices cannot be through a LAN, because LANs only extend across morelimited spaces. It must instead be via the Wide-Area-Network (aka WAN) — which (and in case you did notknow) is simply another title for the Internet.
In comparison to a LAN connection, WAN connections suffer many comparative debilities:
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, andare individually as easy to setup and manage (this is aside from the very large complexity as involved in firstsetting up the VPN itself).
Unfortunately, a VPN does nothing for Item 1 above. In other words, even with a VPN, the speed of aWAN-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 theapplicable data store. When you open a document, the data that describes the document will be pulled fromthe data store, transported across the WAN, and placed into RAM on your local machine, where it will then bemanipulated as you do your work. There will be no need for ongoing communication, with the data store, asyou 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 largedocument, 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 timebecome rather large). Because of this, if the processor that’s running ServiceDesk is in fact across-the-WANfrom its data store, you will see ServiceDesk crawl. It will be ugly. It will be virtually unusable. It is notpractical.
So what’s the solution?
To be very specific, how can we make it so the particular processor that’s running ServiceDesk has noless than a LAN-intimate connection to its data-store, while still allowing some of its users to work in a remoteoffice?
At first blush, it might seem it’s impossible to achieve LAN-intimacy, between a remote office whereinstances 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, thatordinary Windows versions are not.
You’re likely familiar with the fact ordinary Windows can be setup with multiple user logins, each withits 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 isthey 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 userinterface (i.e., mouse, keyboard and monitor). You might call this desktop the “standard” or “native” one. Theothers 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 atechnology called “Remote Desktop” (aka RDP). Remote Desktop is automatically a part of every modernWindows system. If you’re on any such box and have the credentials to login to any virtual desktop as beingplayed 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 serverelsewhere — 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 virtualdesktop 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 multiplevirtual desktops), with workers in your remote office remote-puppeteering it (indeed, not just it, but their entiredesktop 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 ofsecurity.
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 otherswho’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 calledRossware Server Solutions (RSS).
All in all, our purpose in this document has been to help you understand the general concepts. Wehope it has succeeded.
If you are interested in having some idea of costs, at time of this writing Rossware’s RSS servers are $199 setup and$249/mo for base-level service, which is lower than most equivalents otherwise available. If you are interested insetting up your own server, figure a one-time initial investment of about $350 for a server version of Windows (whichcan be run on any PC box), and about $200 for your first five-pack of RDP licenses.
