RDP for Administration Ethics or Code of Conduct

By ssquitiere ·
Has anyone ever written a formal Code of Conduct regarding the utilization of Remote Desktop for Administration? Better yet, is there any professional vendor certification that covers the proper ethics and conduct of utilizing this technology as a measured competency?

Here's why I ask:

I have a vendor which has multiple line of business softwares on multiple servers in our environment. Since I have taken on with my current employer (3+years), I have repeatedly had issues with this vendor's support staffers doing untoward things (e.g. tying up both TS sessions, never logging off TS sessions, leaving one or more sessions active but disconnected for days, etc.) resultantly making it impossible for internal IT/IS to connect to these server elements via RDP without using TSM from another server and forcibly disconnecting the active disconnected vendor sessions. (Note: we do also use a VNC package to get around this). Now, I know that there are policies that I can set which will logoff these idle disconnected sessions, but that's not the point. The point is, that irresponsible use of RDP for Administration is akin to driving without a license and/or ignoring the rules of the road. It is both inconsiderate, as well as dangerous to the public good.

I've tried to re-educate the vendor in the past, and have simply just dealt with and worked around their lack of compliance until now. What has recently aggravated the issue is a result of some of the new behaviors that arrived with the introduction of Windows 2008 and Terminal Services being replaced by the redesigned Remote Desktop Services. Rather than just being reckless RDP drivers as they could with 2003 and earlier, this vendor is now committing vehicular homicide with impunity by utilizing the force disconnect and request to logoff active sessions options now available. Last weekend, and again this, they were connecting to monitor an issue with one of their products which requires an

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Answers

Collapse -

A couple of approaches...

by gechurch In reply to RDP for Administration Et ...

It doesn't sound to me like you need to get overly formal or complicated with this. It seems to me there are two core problems:
* They disconnect other people's active sessions
* They leave their sessions open

I don't see a problem going with the GPO route. Surely setting some policies around RDP sessions is a lot easier and less aggrevating than dealing with running out of sessions etc. Putting a desktop wallpaper on their account that says "Don't forget to disconnect your RDP session when done" might be a gentle, timely reminder too. Should you have to do any of this? No. It's annoying. But that's the situation, and you need to deal with that situation instead of being annoyed that it exists.

I certainly agree that the human response is better though. It sounds like you tried a little to talk to them but gave up. I'd try again, particularly if there are multiple different support people. Just because one person didn't listen doesn't mean they all won't. What you do if that fails depends on how much clout you have with the vendor. I'd ask to speak to their manager and let them know the problem and hope something is done about it. It sounds as though you've got some built up anger over this so I assume there are other problems too. Let them know. If nothing is done then you'll need a plan... can you really leave them? Can a different company provide the support? Can you move to a different product altogether? And, most importantly, does this problem warrant doing any of the above? Only you can answer those questions.

Collapse -

Reponse To Answer

by ssquitiere In reply to A couple of approaches...


Thanks for the feedback. Trust me, I haven't given up. I praise them when they do good, admonish them when they do wrong, and provide constructive criticism for them the whole way through. I've talked to their management, and we even have a special liaison with this company, but despite my attempts to help them continually improve, they repeatedly err and disappoint.

Of course, there are deeper problems. I have one of those jobs with all the responsibility, but none of the authority, and in times when this vendor has seriously erred (and there have been many), my management will side with the vendor despite the findings of their own analysts. I would warrant to say that I have been reprimanded more often for vendor product failures and vendor support/development team screw-ups than the vendor's staff has.

I spoke with the team lead for this vendor's product support unit which most recently erred today. I know her well, and she agreed with me. Their most recent err, has spurred her to schedule a refresher in-service regarding the professional protocol of remote administration. (Note: We had this same exact discussion about 1.5 years ago). In the short-term, I can't ask for much more, but history has shown time and again that their memories are short. To follow your suggestions, I guess I should ask her manager that in the long term this becomes a regular in-service topic, perhaps quarterly, and is also expanded to all other product line groups.

As far as your final questions, can we really leave them? No, not without significant monetary investment to replace the 5 major line of business software products, which populate 25% of our servers (~20 machines), exist on nearly all our desktops, and consume >90% of our storage (I'd estimate a migration cost of at least $1M). All of these products are proprietary healthcare related software, so shopping out the support wouldn't work either. And yes, I push to move away from their products at every opportunity, as with the exception of us meeting requirements for meaningful use stage 1 certification, I don't see how they have helped us grow our business. However, despite their poor track record with us, which our management will acknowledge, it is quickly ignored because of the level of existing entrenchment and some other short term need, for which the vendor ends up selling us something else that doesn't function as advertised.

As far as going the technical regulation route, I suggested this 2.5 years ago, and it largely got shot down with the exception of one server on which I have a 1-session per user and a 15 minute idle time restriction. The only reason I was able to push this through internally is because the vendor session abuse on this machine was delaying the business office from submitting billing statements, and thus having a direct negative effect on cashflow. The main complication with going this route though, is account management. Almost all of the servers I have on which pieces of these 5 products run use specific user accounts to run services and execute scripts that tie into services and scripts on other machines, and require administrative rights. This also gives them the power to do wrong, as they use these same accounts to execute their remote sessions, though I have tried to explain to them before how this is not a good security practice. I even changed all of these passwords once, due to a security breach, and they gave me **** about enough of them for such a long time that most of them are back to the defaults this vendor uses for all their customers (as well as didn't update their support records when I notified them of this such that every product update for 1.5 years that went bad they'd find a way to blame this pwd change for the failure - oh, again, my management didn't support me sufficiently on this). So, can I leave these accounts with their permissions and not break the apps, but also prevent them from being used for RDP....yes, but not without significant changes. Following that change, I'd then have to create either a single shared account for them to use, or one per vendor staffer (for which I'm sure they'd never tell me when these could be terminated). However, I will consider your suggestion regarding desktop background, as we already do utilize bginfo on all of our machines such that they can be readily identified when working on multiple remotes.

Am i annoyed? Absolutely, but I got over being annoyed that it exists a long time ago, and am simply annoyed that it still exists despite repeated efforts to change, improve, and grow together. Again, thank you for the additional ideas to employ in this campaign. I hope they shake some of the stale from the situation.


Collapse -

Best of luck

by gechurch In reply to RDP for Administration Et ...

Best of luck to you Steve. It sounds as though you have done everything you reasonably can, but are stuck between a rock and a hard place. The situation of having poor support and short-term solutions but having the vendor so entrenched in your business that you can't realistically move away is terrible. Nothing short of a time machine, or as you say a million dollars can fix that situation.

Some more unwarranted advice (that I'm sure you're taking anyway):
- Document everything, and be honest and transparent when discussing the vendor with your management. Show an understanding that it's not realistic to move away from this vendor. Don't play the blame-game. Always frame your discussions about the vendor in terms of "there are problems and I want to fix them" (as oppossed to "there are problems and I want to whinge about them").
- Continue to let your management know the problems that are being caused, and what their impacts are (this is where good documentation comes in handy. If you can show a record of recurring problems that caused significant financial/productivity losses then management should be more willing to intervene and demand more from the vendor).
- And over the long-term ask yourself why your management aren't taking your concerns seriously. Is it because they aren't important concerns? Because management don't understand the real impact of the problems? Because they don't respect your opinions? Or are they just short-term thinkers, or not properly invested in their jobs? Once you know what the reason is it should be more clear what your options are to resolve that root problem.

Related Discussions

Related Forums