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.