We at Rezitech pride ourselves on the disambigous nature of our concise communication with current and prospective clients.  However, due to the specifically technical nature of our industry there are some common (often misunderstood) abbreviations and acronyms which are used as a shorthand for framing general IT discussion.  As such, this esoteric second language can become quite impenetrable without a key or guide.  Today, I’ll be referencing and defining a few of these common terms towards the goal of enhancing your understanding of the general concepts therein related.

• NOC = Network Operations Center
  • A Network Operations Center is one or more off-site or remote locations from which control is exercised over a computer network. Essentially, a NOC operates like your in-house IT department; only it performs (often automated) maintenance and implementation tasks remotely via the internet. A NOC is typically responsible for: updating and maintaining server and desktop operating systems to keep them at peek operational trouble-free performance, supervising backups, handling systems administration tasks such as user supervisionand file access, and monitoring the security and stability of the network and all connected systems and equipment. Due to the nature of our global economy, this term has of late become somewhat synonymous with Asian (read Indian) network maintenance/monitoring outsource providers, but this is not always the case.

• VAR = Value Added Reseller
  • A Value Added Reseller is a business entity that adds features or services to an existing product, then resells it (usually to end-users) as an integrated product or complete “turn-key” solution. For example, Rezitech is a VAR for Microsoft products – when we sell a license for a Microsoft Server product; we package it with our knowledge and expertise to configure that product and deploy it effectively to suit the needs and wants of our customer. The added value can also come from our other professional services such as integrating, customizing, consulting, training and implementation.

• MSP = Managed Services Provider
  • A Managed Services Provider is an IT solutions provider, who manages and assumes responsibility for providing a defined set of services to their clients either proactively or as they and/or the client determine that suchservices are needed. Most MSPs bill an upfront setup or transition and an ongoing flat or near-fixed monthly fee, which benefits their clients by providing them with predictable IT support costs while ensuring that their business systems will remain reliably operational. At Rezitech, we provide a full compliment of managed services including email and web hosting, systems backup, IT systems oversight, phone systems, and turn-key total information systems supervision and maintenance responsibility. In short – we are your IT department, helpdesk, and web services host.

• SLA = Service Level Agreement
  • A Service Level Agreement is a part of a service contract where the level of service, scope, and price are formally defined.  This agreement is formalized and documented as agreed to by both parties,provider and client. At Rezitech, when we on-board a client for Managed Services; we contractually define the scope and cost of these services via an SLA.

• HaaS/SaaS = Hardware as a Service/Software as a Service
  • Hardware as a Service is a procurement process similar to licensing. Generally speaking, anMSP (such as Rezitech) monitors and administers hardware on a client’s site on a subscription basis. In order to standardize on best practices and current technology, we as MSP also provide on-site hardware and software for our clients and build its cost into their fees.  For example – when a client needs a new server; instead of investing the capital required to purchase the hardware and software outright, we procure the hardware and the software licensing and provide it to the customer for a monthly contractedfee. This reduces the total cost of ownership and ensures current technology will always be deployed. Our HaaS contracts generally include a schedule for replacing and upgrading the hardware and software; usually every few years. This ensures that our customer’s IT infrastructure never falls into obsolescence.

I certainly hope this brief enumeration has enhanced your understanding of how we frame the discussion for providing our many excellent services to our customers. In my next post, I’ll be tackling: just what exactly is “the cloud” and “cloud computing”?

Until then,

Kent

For now, I’m calling it Email2AT, and I expect it to be released in beta early next week. If you gave me your business card at the Autotask event, I’ll be emailing you soon with more inforamtion. If not, you can sign up at www.autotasktoolbox.com.

Anyway, I need to get back to the projects-at-hand, but I at least wanted to drop a quick line and share that I will, indeed, be releasing the beta early next week.

Happy Good Friday!

If you’re unfamiliar with LiveLink creation in general, the Autotask documentation has a lot of great info, as does my blog titled How to Create a LiveLink in Autotask.

Create a new LiveLink and provide it the following settings:

If you’d prefer to copy/paste the information, I’ll include it here as well:

The link is dynamic, and can include variable information about the entity from which the link originates (Account name, Ticket Title, Contact Email Address, etc).

To create  a LiveLink, hover the Admin menu and select LiveLinks Designer (see image to right).

On the screen that shows up, click the “+ New” button at the top.

Enter a name, label, and description of the LiveLink. Select an Entity, then enter the Base URL, Querystring Values, and Form Post Parameters.

Click the “Save and Publish” button at the top, and check the users and departments that should be allowed to access the LiveLink.

Tonight I found it. A website that has tons of scripts installed and ready to use, so that I can now demo stuff without hassling to install, configure, and activate it only to realize it’s not what I want.

Presenting…. http://www.livedemo.com/!

I hate Vista’s offline files feature. It never seems to go online when I want, and it’s always online when I don’t want it to.

Edit: Found a resource which is helping to explain how this works:  http://technet.microsoft.com/en-us/magazine/2007.11.offline.aspx

Being a huge fan of open source solutions, we tried a bunch of open source firewall implementations (pfSense, m0n0wall, IPCop, vyatta, ClarkConnect, Ewido, Shorewall, Smoothwall, Untangle, and probably 10 more I can’t recall). Eventually, we realized that although there were a few contenders that did almost everything we needed (pfSense, m0n0wall, and Untangle, specifically), they were all pretty locked into their feature-set.

If we’re going to deploy a solution across our client-base, we want flexibility to use this solutions for future needs without having to redeploy a new solution. For instance, I can see us adding content filtering for our clients’ employee web browsing in the near future, and we decide to use a filtering solution that is not bundled in whichever distrobution we choose, then we’ll have some trouble.

All that said, we ultimately decided to use a base Ubuntu installation with OpenVPN to provide our site-to-site connectivity. Here’s how we did it.

First, we installed a plain-jane installation of Ubuntu server and included the OpenSSH server packaged during install. We installed Shorewall, Squid, and Webmin from the commandline once we were up and running.

We did this on a server in our datacenter as well as a test box in our office. We used Webmin to manage the OpenVPN configurations, including the creation of a Certificate Authority to sign the OpenVPN certificates and to manage the client and server configurations.

We setup the OpenVPN connection as a routed tunnel (as opposed to bridged) and created a new subnet strictly for the VPN network itself (we chose 10.0.30.0/24). Our datacenter maintained its internal subnet of 10.0.10.0/24, and our office 10.10.10.0/24.

Once we got the office connected to the datacenter, I was able to connect direct from my desk computer (10.10.10.102) to our Active Directory domain controller in the Datacenter (10.0.10.10). It routed from 10.10.10.102 to the internal IP of the VPN server at the office, which passed the packets across the VPN to the VPN server, which then routed to the Active Directory domain controller.

That was a pretty cool feeling. We had a effectively created a branch office of our datacenter network.

I then setup Shorewall to appropriately manage inbound and outbound connections and ensure the security of each network both from each other and from the Internet itself.

As I write this, I’m sitting at Starbucks, connected to my datacenter via the Windows OpenVPN client, and routing from the datacenter back to my office and accessing our QuickBooks data remotely.

I can also connect via internal IP to any of our managed machines using a Remote Desktop Connection or even transfer files from any of our servers to my laptop via the VPN.

Pretty cool, eh?