Consulting 101 – Why Do I Never Take Control of Computers Remotely?

I don't take control of computers remotely because your team must own every action. You run the scripts while I guide, and no username or password changes hands.

This is part 1 of my six-part consulting series. The series explains how I work and what your team keeps afterward.

Why Access Is Handed Over So Quickly

The usual request sounds familiar: send a VPN login, provide an administrator account, or hand over mouse and keyboard control. The team wants relief from a slow server. Passing access feels like removing one obstacle.

I understand that urgency. Still, access and diagnosis are different decisions. Your organization should approve access based on its security responsibilities, rather than treating urgency as a substitute for review.

My sessions run on Zoom while you share the screen. You stay at the keyboard and run everything. I guide the investigation and explain what each step means.

That working arrangement removes the need to send credentials to me. It also keeps your team's normal access rules in place. Nothing is copied off your systems.

I bring 24+ years of hands-on experience and have helped over 400 customers. Those facts explain the experience behind the guidance. They don't give me ownership of your server or permission to skip your process.

Control of Computers Remotely Blurs Credential Ownership

How frequently do you change server passwords under your approved policy? When do you expire or remove logins that are no longer needed? What password policy applies to privileged accounts in your organization?

Those questions expose ownership rather than prescribing a universal password rotation schedule. Your security team defines the rules. A tuning session should respect those rules without collecting credentials that the helper doesn't need.

When several people use the same login, the database records the shared identity. That record alone cannot prove which person performed an action. Responsibility becomes difficult to trace when the credential has several holders.

I don't want your team's accountability blurred by an extra copy of its administrator password. Keep individual identities and approved access paths. Your operator should run the reviewed script under an authorized account.

Read-only diagnostics still require permission. Grant only what the selected diagnostics need through your approved process. A wide administrator role shouldn't be the automatic starting point for a screen-sharing session.

The permission to see server activity also reveals information about other workloads. Review that exposure with the data owner. Choosing a narrow permission doesn't make every result safe to display to every observer.

Cross-Border Responsibilities Stay With Your Team

Consider a data center in the United States holding a customer's data from Canada. An expert joins the session from another country. Several organizational requirements now affect what can be displayed and how the session is handled.

I'm not providing legal advice through a tuning script. Your authorized security and privacy teams decide the permitted arrangement. Avoid assuming that a screen share removes every responsibility attached to remote viewing.

Approve which application window is shared and who can attend. Apply your organization's rules to recording and visible customer information. Nothing is copied off your systems.

That last boundary is part of how I work. It doesn't replace your own review of the session. Keeping control locally gives your team a clear place to enforce those decisions.

A Reviewed Script Beats Control of Computers Remotely

Lag and graphical clicks are a poor combination when selecting objects for a change. A delayed display creates uncertainty about what the next click will affect. The remedy starts with removing hurried, ambiguous actions.

Use a T-SQL script that names the server context and intended object clearly. Read it line by line before execution. Confirm the database, predicate, and expected effect while your operator still has time to stop.

A script also leaves something concrete to review afterward. A sequence of mouse clicks provides less detail about intention. The mouse has no change log.

I check the selected database before interpreting a diagnostic result. I also ask the operator to confirm the instance. Similar object names across environments deserve that pause every time.

Testing belongs before production execution. Try the change in a development or similar environment first. The approved script then carries the intended action and its recovery path into the live review.

Transparency Makes Every Change Reviewable

You should know why a setting is under discussion. I explain the finding, the proposed change, and the evidence needed afterward. Each change also gets a way to undo it.

For every finding, the decision stays with you: do it, study it, or skip it. An explanation doesn't become authorization because the meeting is underway. Record that decision alongside the proposed script.

Save the current value before any change. Keep the undo line directly beside the proposed change line. A screenshot helps orientation, but a saved result and executable undo script provide a stronger recovery record.

Restoring a setting doesn't erase every side effect of changing it. Plans can be invalidated and workloads can react. Explain those effects before calling the undo path adequate for the situation.

Run a Tuning Session Without Control of Computers Remotely

Share one SSMS application window rather than the entire desktop. Silence email and chat notifications before the session. Keep unrelated results and sensitive query windows out of view.

Start with the read-only selections below. They inspect waits, requests, and file counters without changing configuration or user data. Diagnostic queries still consume resources, so keep their scope and frequency sensible.

SELECT @@SERVERNAME AS ServerName, DB_NAME() AS CurrentDatabase;
SELECT TOP (20) wait_type, waiting_tasks_count, wait_time_ms, signal_wait_time_ms
FROM sys.dm_os_wait_stats
ORDER BY wait_time_ms DESC;

SELECT session_id, database_id, status, command, blocking_session_id,
       wait_type, wait_time, cpu_time, logical_reads
FROM sys.dm_exec_requests
WHERE session_id <> @@SPID;

SELECT database_id, file_id, num_of_reads, num_of_writes,
       io_stall_read_ms, io_stall_write_ms
FROM sys.dm_io_virtual_file_stats(NULL, NULL);

For these instance-wide diagnostics, SQL Server 2019 and earlier use VIEW SERVER STATE. SQL Server 2022 and later require VIEW SERVER PERFORMANCE STATE. The operator's account needs that permission, rather than sending an administrator password to the helper.

Query text from sys.dm_exec_sql_text can contain literal customer names or identifiers. The preceding queries deliberately omit text. If you inspect it separately, filter the scope and avoid displaying sensitive literals.

Capture a setting before discussing a change. This example generates proposed MAXDOP and undo scripts without running either. The candidate value demonstrates the process and isn't a recommendation for your server.

The script stops when another setting has a pending change, because RECONFIGURE would apply that change too. It skips min server memory, whose configured 0 can show a small value in use with nothing pending.

IF EXISTS (SELECT 1 FROM sys.configurations
    WHERE value <> value_in_use AND name <> N'min server memory (MB)')
    THROW 51100, 'Review pending configuration changes before generating this example.', 1;
DECLARE @Before int = (SELECT CONVERT(int, value_in_use)
    FROM sys.configurations WHERE name = N'max degree of parallelism');
DECLARE @AdvancedBefore int = (SELECT CONVERT(int, value_in_use)
    FROM sys.configurations WHERE name = N'show advanced options');
DECLARE @Candidate int = 4;
IF @Before IS NULL OR @AdvancedBefore IS NULL
    THROW 51101, 'The required configuration values were not found.', 1;
SELECT @Before AS SavedMaxdop, @AdvancedBefore AS SavedAdvancedOptions,
    CONCAT(N'EXEC sys.sp_configure N''show advanced options'', 1; RECONFIGURE;',
           CHAR(10), N'EXEC sys.sp_configure N''max degree of parallelism'', ',
           @Candidate, N'; RECONFIGURE;', CHAR(10),
           N'EXEC sys.sp_configure N''show advanced options'', ',
           @AdvancedBefore, N'; RECONFIGURE;') AS ProposedChangeScript,
    CONCAT(N'EXEC sys.sp_configure N''show advanced options'', 1; RECONFIGURE;',
           CHAR(10), N'EXEC sys.sp_configure N''max degree of parallelism'', ',
           @Before, N'; RECONFIGURE;', CHAR(10),
           N'EXEC sys.sp_configure N''show advanced options'', ',
           @AdvancedBefore, N'; RECONFIGURE;') AS UndoScript;

Save the generated text outside the screen share in your approved change record. Test it in a similar environment before seeking production approval. Executing sp_configure changes requires ALTER SETTINGS permission.

Keep the results your team needs in its own approved storage. Avoid recording the entire session merely to capture a setting. A focused change record should identify the value without collecting unrelated application data.

Confirm the undo script restores the saved setting for the intended instance. Review it before the proposed change, not after an unexpected result. Recovery instructions deserve the same context check as the forward script.

Let the DBA Learn by Driving

When you run the checks, you learn where each number lives. You also learn why the selected value matters to your workload. That knowledge stays useful after the meeting ends.

For control of computers remotely, the boundary is consistent throughout the engagement. Your team operates the system and keeps every script, checklist, and prompt. The action plan records work still to be done.

The Comprehensive Database Performance Health Check costs USD 2,432 at a fixed price for up to four hours. The goal is useful work and a clear plan. It carries no promised percentage of improvement.

A second authorized team member can review a sensitive script before execution. That review checks intent and target without handing control to the observer. Your normal approval process still determines who can authorize the action.

Repeat a diagnostic together after the explanation. Ask the operator to describe what the returned columns mean. That simple check exposes unclear terminology while there is still time to clarify it.

Carry the Process Into the Next Session

Which step would your DBA feel comfortable repeating without somebody watching? Use that answer to identify the next explanation or practice task. Repeating the diagnostic should require understanding rather than recalling a cursor position.

I keep control of computers remotely out of the arrangement so the customer remains responsible and capable. For help using this approach, see the Consulting page. Bring the problem and your team's approved working boundaries.

Related reading on this blog: Database Performance Health Check: Six Months Slow, Fixed in 75 Minutes and 11 Essential Tips for Avoiding Common SQL Server Performance Tuning Mistakes.

Keeping your hands on the keyboard is not a lack of trust, it is ownership of the work and its lessons.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.