Authentication
Server
Front-end
Web server
7135
7135
7135
Firewall
back-end server n
????
????
????
????
new Web server
instance
????
????
the other team members often, as work
is distributed. They need to coordinate
their actions, hand off long-running
tasks, and consult each other (especially
during troubleshooting). He also interacts with other teams that are in charge
of different areas, such as networks, operating systems, and mail servers.
During our week of observation, one
of George’s tasks was to set up Web access to email for a customer. This involved creating a new Web-server instance on an existing machine outside
the firewall and connecting through a
middleware authentication server inside the firewall to a back-end mail server (Figure 1). George had never before
installed a second Web server on an existing machine, but he had instructions
emailed to him by a colleague as well as
access to online documentation. The
task involved several people from different teams. Early in the week, George
asked the network team to create a new
IP address and open ports on the firewall. Throughout the week, we saw him
collaborate extensively with Ted, a colleague who was troubleshooting some
problems with the authentication server. George’s progress was gated by Ted’s
work, so they exchanged IMs all the time
and frequently dropped into each other’s offices to work through problems
together.
By Friday morning, George had completed all preparations. The final steps
should have taken just a few minutes,
but this was where the action really began. A mysterious error appeared, and
Error: Could not connect to
server (status: 0x1354a424)
own was still connected to Adam), but
quickly transitioned communications
with tech support to IM. For the next 20
minutes or so, George continued to troubleshoot with Adam on the phone and
tech support via IM, and Ted kept popping into the office to offer suggestions.
After a while, George became unhappy
with the answers from tech support, so
Adam hooked him up with one of the
developers of the middleware, and they
started discussing the problem over IM.
Throughout, George remained the sole
person with access to the system—all
commands and information requests
went through him. He became increasingly stressed out as the problem remained unresolved.
Eventually, Ted went back to his own
office and looked into the problem in-
dependently. He discovered that George
had misunderstood one of the front-end
server’s network configuration parame-
ters, described vaguely in the documen-
tation as “internal port.” George thought
this parameter (port 7137) specified the
port for communication from the front-
end to the middleware server, when it
went the other way. George, in fact, had
made two mistakes: he didn’t realize that
every front-end server used port 7135 to
talk to the middleware server (which was
permitted by the firewall, see Figure 1),
and he specified a port for communica-
tion from the middleware server to the
front-end, 7137, that was blocked by
the firewall. Communications worked
in one direction, but not the other. The
software only tested communications
George spent more than two hours
troubleshooting the error, mainly in col-
laboration with others. He had created
the new Web-server instance seemingly
without incident, and it registered itself
with the middleware authentication
server. Yet when he issued the command
to the middleware server to permit the
front-end Web server to talk to the back-
end mail server, he got the following
message:
Given that three different servers
were involved, the error message gave
him insufficient information. The on-
line docs and a Web search on the mes-
sage provided no additional details, so
he reached out for help. (For more on
error messages, see “Error Messages:
What’s the Problem?” ACM Queue, Nov.
2004.7)
