This is the first of a 5 part series on my 10 years of experience in Comprehensive Database Performance Health Check consulting engagement. Here are the five blog posts that are the essence of my consulting business. You can also call it as my business secret. In today’s blog post we will discuss one of the most popular questions I receive – Why Do I Never Take Control of Computers Remotely?
- Consulting 101 – Why Do I Never Take Control of Computers Remotely?
- Consulting 102 – Why Do I Give 100% Guarantee of My Services?
- Consulting 103 – Why Do I Assure SQL Server Performance Optimization in 4 Hours?
- Consulting 104 – Why Do I Give All of the Performance-Tuning Scripts to My Customers?
- Consulting 105 – Why Don’t I Want My Customers to Return Because of the Same Problem?
Why Do I Never Take Control of Computers Remotely?
The common practice is to ask for either mouse and keyboard control, server login using VPN or SQL Server Admin Username and Password. I never ask for any of these. Unlike most of the SQL Server experts, I will never ask for your server access and there are many reasons for this. Let us go through them one by one.
Why I Never Take Control of Remote Computer?
The common practice is to ask for either mouse and keyboard control, server login using VPN or SQL Server Admin Username and Password. I never ask any of them. Unlike most of the SQL Server experts, I never ask for your server access and there are many reasons for it. Let us see them one by one.
Reason 1: Security Aspects
Let me ask you a few basic questions: How often do you change your username and password for your server? How often do you expire your user’s login details so that they have to recreate new logins? What is the policy regarding secure passwords in your organization?
My years of experience have taught me that people hardly ever change their username or password. When a customer gives me their username and password, it is quite a big responsibility. When any organization shares usernames and passwords easily with multiple consultants, they all now share the liability among them.
Think of it in this way, if someone else who has the same security credentials does anything ‘bad’ to the server, who owns the responsibility of the wrongdoing?
Well, there you go, I personally do not like to receive security credentials of the server so if something not so nice happens, at least you know it was not done by me.
Reason 2: Legal Aspects
The world is getting smaller and smaller but there is no denying that we are all quite different. Different parts of the world have different types of privacy policies and user data protection rules. There is no way that one person can know everything. Additionally, not every organization is in truly global or can hire world expert lawyers.
Let me give you one example if you’re a data center in the Netherlands holding the data of a Canadian customer. Let us imagine the expert is a resident of South Africa and accessing the server from his business location in the US. In this scenario, interpreting privacy laws can be very complex.
Whenever any organizations try to give me VPN access, I refuse to accept it not on technical grounds but because of the legal aspects. I am not worried about myself usually but rather I am worried about my client and their customers. I do not want to create any complex situations for anyone.
Reason 3: Human Error
I have seen this problem so many times that I couldn’t count with a chess board. If I use a logarithmic counter to count human errors, I could probably count. When we talk about remote connection and remote networking, we must remember there are two evils – Network Speed and Network Latency.
Let me tell you a true story. While working remotely, one of my DBA friends noticed that there was an additional index on the table which was not needed. He decided to drop it with the help of SSMS. He right clicked on the server and voila, he got the drop option in the menu. As soon as he clicked on the drop option and confirmed his action in the confirmation box, he realized that instead of index, he had dropped the entire table. This was a major setback and it had happened because when he clicked on the drop and when the drop was executed there was a huge latency. It was a huge mistake.
I always suggest that my clients use their own local network and comfortable method to access to their server to avoid errors.
Reason 4: Transparency
When we eat food we want to know exactly what it contains, we might ask our chef to be sure. Additionally, it is important that customers know exactly what is happening with their server. There should not be any black box behavior with the customer where they have no idea what is going behind the scenes.
I personally believe in the concept of mentoring and coaching. I want my customers to learn along with me rather than me keeping them in dark. I want them to know every single detail about what has been done to their server so that next time, when they face a similar situation, they can do it themselves instead of hiring me for another consulting engagement.
Well, that’s it. I hope this long blog post gave you an idea of why I never take control of the client’s system. I want them to learn from me and I do not want to keep any secrets!
Reference: Pinal Dave (https://blog.sqlauthority.com)