Security·4,733 discussions

Network vs. Pc support

Locked

our network admin. battles with our pc suport admin. over letting the pc techs to access certain aspects of the cisco routers. the tech say that if allowed they could make repairs more efficent and get users up and running faster than the network group.there are 2 network guys and 5 pc techs. the network admin cites security and fewer hands on the network as his rationale for not wanting anyone else on the networks and the pc techs feel control is his main reason.

Topic

Common

In reply to Network vs. Pc support

Years (many) ago, when I was on desktop support, we had similar problems. Our responsibility and authority ended where the wire hit the wall. Even though I knew more than some of the N/W techs, I wasn’t allowed to touch anything on the network.Ralph

Boundaries

In reply to Common

I think it is human nature to create boundaries.

The flip side to managers restricting actions by department is workers responding with “not my job”. I had a miserable quarter when help desk personnel would call me at all hours to validate whether the network was up or down because network was “not their job”. What really hurt were the calls where they had identified a circuit outage by CSU indicator lights, but were afraid to call the carrier! Training on how to interpret available symptoms, how to call a carrier to report a circuit outage, and a difficult sales job to their manager on why this was not doing network but simply speeding the resolution process finally resolved the issue.

One way to look at it.

In reply to Common

It is funny topic if you ask me considering that the System Administrators and PC Technicians would scoff at the idea of giving Administrative, or root, access to their systems and then expect the network elements to be different. There are many cases where the lonely Network Administrator could isolated a problem if just one more system was available for them to test from. Of course this is not everyone; just some.

Share knowledge for benefit of everyone

In reply to Common

Personally, I’ve never subscribed to the whole “knowledge is power” mentality. It’s a pathetic and insular way to conduct your life, working or otherwise
I welcome any genuine interest from helpdesk people in my organisation who are willing to learn. If they choose to use that knowledge in a negative “backbiting” way then ultimately I believe it will come back on them.

Think what, not how

In reply to Network vs. Pc support

There are some legitimate reasons for limiting access to routers, particulary when access is for changes. A properly designed network, implemented with correct configurations, should only change in response to changing requirements. If routers arehaving configs changed in response to troubles, the design or its implementation was faulty. If services or ports are being routinely reset, it indicates a problem with the hardware or IOS.

Keep in mind that an “Oops” on a workstation impacts that workstation, or at worse a LAN segment. An “Oops” on a router can bring all communications on an intranet down.

Likewise, a security snafu on a workstation is still backed up by site security and worker integrity. A network security snafu canopen the intranet up to the world.

I would approach the issue from a what, rather than a how, approach. Let the network administrator know what information your PC support is looking for and why. Forget about pushing router access, let the network admin determine a solution that meets your requirements and leaves him comfortable.

Network Admin Is Right

In reply to Network vs. Pc support

I have to side with the Network Admin, I’ll go a step further and say — “Why does the PC support techs need access to the routers/switches anyway”?

I mean I’ve been a PC support tech for many years before I got interested in networking – I know what you need to support PCs, and I never needed to change router settings or fuss with a switch to provide PC tech support.

If you have network admins to take the networking problems/calls and the PC support techs to field the standard helpdesk calls — AND the PC support techs are saying they need full access to the routers, it is, IMHO, that the PC support techs are the ones with the control issues not the Network guys.

The network guys are doing what they should do — fighting to keep as few people as possible from messing with the network configs.

The N/W techs are very right…

In reply to Network Admin Is Right

Just wait until one of the PC tech’s decides to take a CCNA course….the routers will be all over the place within days !!
I would never permit PC techs access to routers, or other major network hardware. If they feel the need to control this equipment, they must become network techs.
Each job also needs a hard boundary. It’s nice to work into the grey areas, but once you have a cock-up, you’re screwed and you would find the network techs, and PC techs would slowly turn on each other.
There’s also the knowledge required for network admin. It is very different to PC tech supp, and I would say that no matter how much you claim to know more than a N/W tech (not to say you are lying), there is something that makes them the N/W tech, and you the PC tech. It’s probably experience with infrastructure communications.

One stop shopping

In reply to Network Admin Is Right

When the help desk dispatches a call for a end user who can’t get onto their machine, they really don’t want to hear that you can’t fix their problem and someone else has to be sent out to repair something as simple as replacing a port on the switch and reconfiging it. Time is money. As for control the NW guys have set the network up so that everything that the PC group does they have to depend on NW guys the for the fix, this causes dependency

Approach

In reply to One stop shopping

I am going to assume that key focus of the PC team is customer service with an emphasis on the fastest possible time to restore. I am also going to assume that the key issue for network is risk rather than control, but that the discussion has movedoff the real issues to a focus on control.

My suggestion is a responsibility nuetral flow chart of problem resolution. Try to cover at least the top 80% of the reported problems in this effort. Try to identify the steps taken for problem identification and resolution.

Now focus the emphasis on actions and order to provide the best possible support to the users. Perhaps a first step on a trouble should be a switch port reset prior to tech dispatch, for example. As a side note, if port resets, or port changes and reconfigurations, are fixing many of the problems then your organization really needs to look at getting vendor support or changing switch manufacturer.

Once the focus is on what instead of who, you may find the networkmanager requesting certain routines to be moved to your team’s responsibility.

professional growth

In reply to Approach

there is only so much you can do on the PC end, where do the techs go from here professionally. Each tech has the (mental)appitude to make our organization better. The fact that I omitted is that the NW admin is the only person who works on the NW issues. What If something happens then. This makes our organization hostages to his decisions.

Flawed logic

In reply to One stop shopping

Your logic is flawed. In your scenario you answer the question for yourself — its its a port on a switch that is bad, why does the helpdesk dispatch PC support in the first place and not the network support techs?

This scenario is 100% network, hence PC support shouldn’t be called.

Two different responsibilities

In reply to Network vs. Pc support

The routers should not need reconfiguration often enough to justify desktop support access if tehre are designated network support staff on hand.

If the routing and addressing schemes are in place, network problems should be few and far between.
The probability of a router change being the fix for a desktop problem is low. Usually a network layer problem will affect large numbers of users at a time, and look like a network problem when a large number of similar trouble tickets arrive.

Off the cuff, I’d say this is an interdepartmental power grab, not a control issue.

My Experience

In reply to Network vs. Pc support

very impressive team of System Administrators. This team was a great help to the small and inefficient network administrator that took on way more than he could handle without the say-so. What happened was there were two network administrators, one very knowledgeable and one not knowledgeable. The knowledgeable one left the company for more money and handed the not yet finished design to the newbie. The newbie tried very hard to put the network together and managed to complete the task so that every network can ping each other that is supposed to?this is all the is required?right?

My Experience (continued)

In reply to My Experience

Let me list some of the ?features? of this network that was designed little by little by a scattered team with different interests:
– Access Lists on every interface that have up to 300 lines when only 20 are being used. Imagine the poor routers having to analyze 280 lines of code that will NEVER be touched
– VLANs so badly scattered that you could take three layer 2 hops to an IP interface directly connected to you.
– Routes being learned from Edge machines(UNIX) just because they can and being preferred over the Backbone!
– Loops that I can count on two hands with only one device between the two clouds.
– A fully redundant network that can be isolated to the world in a single cable failure or mistyped command.
– IP address schemesthat waste every other 64 addresses.

I went through this network and it took me three months to fix it without affecting others too much at one time. Through my audit I learned that all of these crazy changes were made by huge handful of very smart people, if one would have been in charge the design would have been flawless.

Some of you are thinking that I am forgetting about troubleshooting and only focused on design. Agreeing with one of the responses outlining a troubleshooting flow chart it could cheaply and simply be done where as the PC technicians have adequate access to troubleshoot only and the network administrators still get to keep the integrity and consistency of the network. There are *multiple* ways to accomplish this and make everyone happy if the objectives are just laid out.

Good Luck on your (Network vs. PC)!
-Jim

SLA and RPP!

In reply to Network vs. Pc support

Just read most of the comments and two key terms missing. Know what reaction times are necessary for the resolution process procedure (RPP). When bottom layer (tech.) acts, it is to achieve the SLA and use existing RP procedures. As appropriate to achieve your SLA, modify RP procedures. When a member leaves the team, it would not matter and RPP would be modified. Indeed, this is the job of the team managers, but I have meet a few that misses the mark. SLAs are not only for organisations; smallcompanies should also implement such performance milestones.

TheSourcePortal

It depends on the environment.

In reply to SLA and RPP!

In my last company there were 3 of us. (1 Network, 1 PC (me), and 1 DBA)

So we all needed to know a little bit about each others jobs to help with minor issues if one of us was busy, offsite, etc.

So aside from that I dont see any reason for PC techs to be messing with the routers very much. The question I would ask is, if you mess up the router, can you fix it? I know I could not, so I limit my actions on the routers/switches to cable management, rebooting, and other simple stuff.

3-man outfit

In reply to It depends on the environment.

In your 3-man show, this is actually achievable. 1. RPP could be verbal. PC tech can launch a DB admin script prepared by DBA

2. Router changes are not everyday tasks, but let’s say a CSS device can see up to 25 changes in a day. Standard RPPs can allow Networking trivial for the network admin such as rule changes or an NT domain account clean-up to a techy.

3. Procedures clear and with specific objectives can make your team more effecttive and demonstrates efficiency. Even your three man team can assign SLAs and work together to achieve team objectives.

TheSourcePortal

More on the 3 man team.

In reply to 3-man outfit

We did not go so far as to offer SLA’s we had been downsized from 11 to 3. And now its 2 ( I got laid off during a big riff ) But we worked pretty well as a three man team. The only thing that was annoying, was at first the network guy and I did not sit in the same area.

We were in different buidlings, and this caused some confusion as to who was helping who, since 95% of all customer issues came to the two of us.

Once I moved near him, we were able to hammer away issues, and more importantly exchange ideas on troubleshoooting issues.

It all boils down to

In reply to Network vs. Pc support

How much you trust your staff. In actuall fact the techs could gain access to anything on the network if they really wanted to but in most cases they are simply involved in repairing the things in a fast and efficent manner and aren’t all that concerned on what they are actually working on or more precicely it’s contents anyway.

Once upon a time I had the same trouble and this ceased when I draged something very important off the network and handed it to the Admin. Now I administer the network which is for a bank so the data fairly private and I trust all my staff with any part of the WAN as often we have to drop everything and race out to a remote branch to do a fix that requires what I term super Administrator access. We do this witha LT and floppy that contains the subroutine for the LT without each other the things are useless but together you have complete access to the entire network wich is necessary for repair work but a hinderance at any other time.

If the Admin doesn’t trust the techs then there will be no way of changing their mind as they are parinoid about “security” but on the other hand if you can’t trust your staff then they simply shouldn’t be there in the first place.

[Author]

Replies