|
Executive Summary: Many Windows system administrators and network administrators rely on the Windows administrative GUI to manage their servers. However, when one administrator applied patches to the servers in his company’s data center, a problem arose that prevented him from accessing the GUI. The administrator found the SC command-line tool (Sc.exe), which let him remotely access the server and troubleshoot the problem to get his systems back online with all services restored. |
As a computer consultant, I often encounter system administrators who find themselves in trouble if they can’t perform an action through the GUI. With many good command-line tools available, and resources such as Windows IT Pro to learn about them, admins should have a variety of methods in their toolbox to solve problems.
Here, for instance, is the story of a Windows administrator—we’ll call him Frank. He relied mostly on the Windows GUI administrative tools to perform systems management tasks. However, one day when Frank couldn’t access a crucial server in his company’s data center, he had to find a command-line alternative to solve the problem. Here’s what happened.
RPC Server Lost at Sea
On a certain Patch Tuesday, Frank had servers to patch at a data center. It was easier for
him to apply the patches from a remote connection, so at around 9 p.m. he logged on to the
system and patched all the servers, including the domain controller (DC) with the Global
Catalog (GC) role.
After he rebooted everything, the servers all responded to a Ping. But when he tried to check his email, Microsoft Office Outlook couldn’t find the Exchange server. Then he tried logging on to the DC but received an error message: The system cannot log you on due to the following error: The RPC server is unavailable. The good ship GUI was heaving and swaying in the waves, with no access to the GC role. Without this role running on an Active Directory DC, Exchange can’t run.
Frank was desperate to find out what was going on with the server, and he remembered that he could use a Microsoft Management Console (MMC) snap-in to read the logs of another server. So he logged on to a member server to try running the snap-in but still couldn’t reach the DC. Frank had run aground on an uncharted island, unable to reach the “mainland” of the DC, and he couldn’t get any information from the system to help solve the problem.
As he paced around, trying to think of a way out of this situation, he tripped over a laptop bag that appeared as if washed up on the sand. Looking inside, he found an issue of Windows IT Pro. With no better ideas, he started paging through the magazine.
SC Tool to the Rescue
Suddenly, he saw an article about a command-prompt tool he hadn’t
been aware of: SC (sc.exe), a tool that could be used to manage services
running on a local or remote machine. The article was “The All-
Purpose Service Controller,” November 2006, InstantDoc ID 93400. As
Frank read the article, he thought, “This tool could help me out of my
predicament.”
He logged on to the member server again and entered the SC command in the command window to learn its syntax, which came back as
sc <server> \[command\] \[service name\] <option1> <option2>...
Frank soon realized this wasn’t a one-use tool, but a Swiss Army knife that would return him to the GUI and restore email service. He knew the server wouldn’t respond by machine name, but it had responded to a Ping. So he entered this command:
sc \\192.168.10.10 query
In an instant, all the server’s services and their information scrolled down his screen. He needed to narrow down the query to a specific service. According to the connection error message, the remote procedure call (RPC) service wasn’t available, so Frank entered the following command to see what was going on with RPC:
sc \\192.168.10.10 query RPC
The command returned an error message: \[SC\] EnumQueryServices Status:OpenService FAILED 1060: The specified service does not exist as an installed service.
From this error message, Frank deduced that the SC command didn’t recognize the RPC service’s display name (i.e., RPC), so he retried the command using RPC’s service name, rpcss. This time, the command results showed him that the RPC service was running, although the logon error had said the service was unavailable. Now Frank was really confused. Looking further at the query results, Frank noticed the State parameter. A State value of 4 means the service is running.
Homing in on the Problem
He ran the query command again without specifying a service and
looked at the states of all running services. Eventually he noticed that
the Netlogon service was paused. Perhaps this was the one thing keeping
him out of the server.
He didn’t have access to services.msc to start or stop the Netlogon service, but he had the SC tool. So Frank entered the following command to stop the Netlogon service:
sc \\192.168.10.10 stop netlogon
Then he queried to see the results of the previous command by entering
sc \\192.168.10.10 query netlogon
which showed him that the State value for Netlogon was now 2, meaning the service wasn’t running. He then ran the following command to start Netlogon:
sc \\192.168.10.10 start netlogon
To see this command’s results, he again queried Netlogon and saw that the service was running. Eureka! He had restarted the service from across the network by using the SC command-prompt tool.
Frank was now able to log on to the DC; all the GC server services were running and email was working. He had escaped from Command- Prompt Island and was back aboard the good ship GUI. It just goes to show you: Having the right tool is like wearing a life jacket when sailing in calm seas—you might not need it, but you’ll be prepared should a sudden, unexpected squall hit.