The concept of telecommuting is arguably the most controversial working arrangement to evolve from the 1990's technological revolution. The concept of a standard five-day work week, with a structured set of scheduled hours, has been "the norm" since the 1940's. With this structure comes the accepted wisdom that if you're not at work, you're not working. Despite all the changes in recent years, this is hands-down still the greatest obstacle you need to overcome in order to get the approval you need to start your grand telecommuting experience.

In the days before the Internet, laptops, cell phones and PDAS, commuting to your place of business was a necessity. In order to get business done, you needed access to your desk, office equipment, telephone, and support staff. Now, that access is easily accomplished by other means. No longer is it necessary to hover over the fax machine; just send the documents by email. Need to meet with the project team to review specification changes? It is as simple as opening up a conference line. Just found out there was a performance issue with a database you support? Of course you did, you received all the details via a text message to your PDA. Need to chat with a colleague who is also working remotely because their child is home with the flu? Simply ping them using the instant messaging application on which your company has standardized.

Anyone who carries a pager, clutches the on-call cell phone, or is in some other way anchored to work on an as-needed basis, is already telecommuting. The goal of this article is not to tell you how to convince your company to let you formally telecommute. Instead, what I hope you take away is an understanding of what it requires to work remotely – not just the tools you need, but the also character traits. I'll also describe some of the sacrifices you'll need to make, which balance out the many benefits inherent with working from your home. For the most part, I focus on remote working as it applies specifically to the DBA. However, many of the arguments I discuss apply equally well to all remote workers.

The obligatory personal history section

– "Hello, my name is Tim and I am a SQL-a-holic."
– "HI TIM!"

Databases entered my life in 1999 and I have been immersed in a love-hate relationship with Microsoft SQL Server ever since.

I've been a telecommuting DBA since early 2000, working for a large healthcare company 65-miles north of our home. My wife has a successful career of her own and we decided that the commute was better for our family than a physical move. We were, and still are, very happy with the cost-of-living and quality-of-life in the area of Michigan in which we live.

In the early days of my 650-mile per week commute (with gasoline in the United States reaching an insane price of $1.80 per gallon), I began to seriously consider looking for employment opportunities closer to home. However, at the time, I did not have enough knowledge of SQL (or current technology in general) to make it as an independent contractor, so it was not an option. I was fresh from the printing industry, doing estimating, and using my accounting degree and my love for computers to cobble together an estimating program from Visual Basic 5.0 and Microsoft Excel.

Eventually, through a self-learning regimen, I cultivated enough knowledge of T-SQL to land my first technology position as a Microsoft Access developer. Even back then this was not a very marketable skill but, fortunately for me, Access Developer soon became SQL Server Developer when our company began to see that Access databases were not sufficiently meeting the needs of our customers. Over the next two years, I gradually took over the role of the Database Administrator, earned my certification, and grew our SQL Server environment from a single server with 13 databases to a domain of 15 SQL instances and over 100 databases.

Even at the time when the technology required to work remotely was in its infancy, I felt that I could successfully perform all my assigned job functions without needing to be physically located inside the veal-cage that is my office cube. I screwed up the nerve to ask my manager, and he agreed to allow me to start a trial period of working two-days per week from home, with the condition that it had zero-impact on the customers I serviced.

Fast forward to 2008, and I've been the solitary SQL DBA for our company since 2001 and am telecommuting three-days per week, minimum, from my home office and supporting over 70 SQL instances and 800+ databases.

It's All About Making Connections

So, how do you do it? How do you work effectively without being at work? Well, practically, and especially from the DBA's point of view, it all comes down to connectivity and tools. If you have the necessary tools and a solid, secure VPN connection to your office, then you will have no issues with remotely working from any dry surface on the face of this planet (not to mention a few wet ones as well!).

The Remote DBA Toolbox

In my experience, the Remote DBA Toolbox needs to consist of the following applications, technologies and concepts:

• Internet connectivity – Whether by WiFi, T1, air card, or wired connection via the method of your choice (DSL, satellite, cable, and even dial-up.)
• SQL Management Tools – Microsoft native management tools or your third-party tools that you rely on in the office; you need 'em remotely too.
• Remote Server Access – The need to be able to physically connect to your SQL servers, via terminal Services / RDP, is as critical as having the right SQL management tools at your disposal. This means being a member of the Remote Users local group on the server(s) in question.
• Local Administrator Role Rights – It may be a fight, but it is a fight worth winning. Does your company want a DBA that needs to jump through hoops to get their day-to-day work done or do they want an efficient resource?

Taking Internet connectivity as a given, let's explore the other three in a little more detail.

SQL Management Tools

For the DBA, having the necessary SQL tools mainly means having SQL Server Management Studio, or SQL Enterprise Manager, loaded on your laptop, or remote workstation, in your home office. Additionally, many of us have third-party management tools to which we are attached (a shameless plug to you, SQL Prompt!) and these should also be loaded along with any configuration and performance monitoring tools that you need. You can perform remotely every task that you would normally perform through these tools just as well as if you were in the office. '

Remote Server Access

Almost as critical to the remote DBA as the appropriate SQL management tools, is the ability to utilize Terminal Services / Remote Desktop (RDP) technology.

For the most part, the modern DBA is not the "hands-on-metal" technician of years past. A result of the continual evolution of operating systems and the associated hardware required to run them, has made it commonplace for companies to staff their Information Technology departments with dedicated Server Engineers responsible for the physical servers on which our databases run. Any task that might require physical access to the servers, such as patching the O/S, adding memory or configuring RAID arrays, generally falls into their realm. DBAs will make the recommendations for the systems to purchase, disk configurations to use, and amount of memory and CPUs but, quite often, we're not involved with the server until it is time for the installation and configuration of the database software.

Personally, I support around 80 SQL instances and I've only been in our Data Center twice and the first time was only because I was curious to see what it looked like! My main point is that whether you work in the office or at home, you will be accessing the servers remotely, so both office and remote DBAs need access to the same remote desktop technology.

In short, as a remote DBA, you need terminal services / RDP, and to be a member of the Remote Users local group on the servers for which you are responsible. Coupled with a secure and durable connection to your network, you can then support the environment with identical performance and efficiency to an office DBA.

Connecting to a server for the purposes of installing SQL Server and its components, configuring clustering or other means of high availability, migrating physical files, checking volume space; all these things are made possible via RDP.

Most DBAs are tasked with migrating data, log, and backup files, when necessary. For example, quite often we need to migrate databases between SQL instances and physical servers, or provide backups to vendors for support purposes. Even with today's high-speed connections, this is one task that can be a little slower when working remotely. However, without RDP access the situation is much worse. In figure 1 below, if you are able to login to either of the servers with Remote User access rights you can move the files easily with minimal copy time. (Option A)

Figure 1

However, if you are unable to "remote-in" to either of these servers it would be necessary to open up a Windows Explorer window for both servers and then copy the file(s) as necessary. The issue with this option (B) is that the files are physically copied from the production server to the laptop and then finally to the destination development server. Depending upon the size of the file this may be a significant productivity hit. This reason alone is the basis for requesting Remote Access user rights for the members of the DBA team in your environment.

Local Admin Rights

Of course, RDP technology is of minimal use without the proper security level access. It is the primary job of your company's Server Security Engineers to make sure that the servers in your environment are protected from outside intrusion as well as internal misuse. This is identical to your role in protecting the database from improper access as a Database Administrator.

As a remote DBA, you need to make a strong case for having the correct access to the servers you need to support. At a minimum, in order to use RDP technology, you need to be a member of the Remote Users role on the server. This membership is inherent to the Local Administrators role, but it can be argued that you do not necessarily need to be a Local Administrator to successfully administer the SQL instance on a server. However, if you are tasked with controlling a Windows service, then the DBA account will need to be a member of the Local Administrators or Power Users group. Likewise, if you are responsible for Service Pack and hot-fix installations, then you will need to be a member of the Local Administrators group.

Other than those responsibilities, a local user with full rights to the backup, data, and log directories, as well as Read and Execute permissions to the \MSSQL folder (MSSQL$ folder for a named instance) should be sufficient. This may seem restrictive, but it is the SQL services that need to have the greater level of rights to the server. Since the services should run under a different domain user account than that of the DBA, the DBA rights can be more-restrictive. Know this when you ask for rights to your SQL servers. Just like any negotiation process, you should aim high and know what your limit is beforehand.

I strongly suggest that the DBA(s) in your company (at least the Senior DBAs) have access to the login and password assigned to the SQL services for each instance that they support, if the DBA rights are restricted on the server. There will be times when the DBAs may be called upon to perform tasks that require them to either impersonate the service account or to be able to enter that information in order to configure the SQL instance (think SQL Server installation and configuring of the services.) Your company should be auditing logins and with the knowledge that the service account login and password has been restricted to only select individuals in the environment, if issues do arise responsibility can be assessed quite easily.

The Personality Profile – Can Everyone Be a Successful Remote DBA?

Having the right tools is only half of the solution. You also need to be able to be the right tool. Some of those who know me will claim that I am a Tool with a capital-T, but I digress. What do I mean by "be the right tool"? From my years of working remotely, I've found that the following traits must be inherent in the personality profile of the candidate DBA, in order for them to be an effective remote DBA:

• Able to work without a level of socialization that comes with being an office employee.
• Possesses excellent time-management skills.
• Able to resolve issues independently or know where to go for a resolution.
• Excellent written communication skills.
• Dedication to the company, its staff, and its customers.
• Realization that remote working is a luxury, not an entitlement.

A remote worker functions outside of the daily socialization of the office environment. If you are the sort of person that thrives on the camaraderie, the gossip, the after-hours social events of the office, then the chances are that your productivity will suffer when working remotely.

The remote worker needs to be highly disciplined and, to a large degree, self managing. You will not get the same level of day-to-day contact with your co-workers, managers or directors that you would get when working in the office. This also means that you will need to maintain a higher level of written communication with your team, and with the person you report to.

Constant emails back and forth are not the solution. What I find works best is to involve these individuals only when you need assistance that their clout may provide. Other than that it is your responsibility to keep them informed at a level they need. While you are accountable for the work you do, so are they. Keep your Managers informed in a daily summary so that they are never blind-sided by something for which you were responsible. An added benefit of this daily status report is that it provides a running commentary of your work. I BCC myself on these communications and have set up a rule that will drop them into a dedicated Outlook folder. I use this information to track my time for projects and more importantly, for justifying items on my annual performance review! How good are you with remembering all the projects you worked on over the course of a year? If your job is anything like mine, you spend many a night with your favorite "Barley Pop" trying to forget what you were working on that day!

Communication to coworkers is a difficult process in its own right. You need to try your best not to get involved in email see-sawing that could be better handed in an IM session than in a thread of emails. Work hard at understanding where an email conversation should end and an IM session should begin

Finally, what has made me a better remote worker is always treating the ability to work remotely as a privilege - not a right. By treating it as such I've made sure not to abuse the right to work remotely.

Go Home and Get back to Work!

The intention of this article was not to tell you how to get your boss to let you work from home. There is absolutely no single way to accomplish this. Heck, I may have just caught mine on a good day right after he filled up his tank and cursed as he saw how much he had to pay for gas. I'll never know for sure – I'm on my third manager since. Funny how that works, eh? Each of my managers has recognized that the arrangement has been completely successful for both myself and the company. Even a manager who was against the concept of telecommuting knew not to tinker with a successful arrangement, realizing my customers were satisfied and well-supported; my servers and databases consistently performing above standards; and that he gained an extra hour or two of productivity from me while I worked from the comfort of my own home office.

Telecommuting is not a workable solution for everyone or every company. Those individuals who thrive under the confines of the arrangement though will evangelize about it to anyone who is willing to listen. Whether you realize it or not, you just sat through my sermon on the matter. Now go home and get to work!