March 28, 2006 at 7:04 am
I have just started at a new company where I am responsible for several SQL Servers in several different domains. Convincing the network folks to give me access (beyond SQL Server access thru EM) to the servers has been difficult at best. Despite that fact that having no remote access to the servers or the ability to map drives to the servers has limited my ability to do basic tasks (like restoring backups on other machines) the network admins are still refusing to allow me to have remote connection abilities nor access to SiteScope for remote monitoring nor the ability to access drives over the network.
I need help convincing them that this type of access is typical and even necessary for a DBA. Any arguments to this affect are welcome!
Thanks,
Gordon Pollokoff
A "restricted" and frustrated DBA
Gordon Pollokoff
"Wile E. is my reality, Bugs Bunny is my goal" - Chuck Jones
March 28, 2006 at 7:42 am
Gordon,
There could be good reasons to limit your access. Not that I'd like it either, but you should work within your limits. If you need a test restore, then note the time, request the file transfer, and note when it's done. Same for other information. Request it as needed and if it interferes with your job, let your boss know. Otherwise, if they can respond in a timely fashion, then go with it.
Not that I'd condone it. Is the service account a local admin? Try some xp_cmdshells and see what can be done.
The biggest argument for access is expediancy in your job. Being able to get done what you need. This is something you have to see if you need over time. There's also testing patches. That requries console access usually and if they give you a test server, then go with it.
Not sure what Sitescope is, but if they can give you data, then you don't really need access.
March 28, 2006 at 8:03 am
Steve,
Currently, I am working within my limits. However, the need to perform basic tasks like restoring backups on other machines is taking way to long (determine which backup to restore, get an admin to copy the file to the target server, then restore the backup). Unfortunately, the admins don't jump when I bark!
Most recently, I am trying to debug a failing job that is restoring a db from a UNC path name. Rather difficult to sort out what is going on if I can't even access the UNC path.
Now I've been asked to justify my need for access. Hence, the post.
Gordon
Gordon Pollokoff
"Wile E. is my reality, Bugs Bunny is my goal" - Chuck Jones
March 28, 2006 at 10:51 am
If I were an internal admin, and it would be my butt on the line or me getting the midnight call when there was a problem with the server, then I would fight requests for remote access from third parties quite hard. Remote access generally involves granting local admin rights, which grants that third party enough rope to hang me well.
I'm not saying it's right or wrong, just trying to set up the other side's point of view.
To make the argument, it all comes down to time and money. If it can be quantified, it can be justified.
Money: Be sure to bill them for every single wasted minute, including the non-technical stuff like chasing admins to check on files. Inform your client of the potential savings if you could simply do your job and be done with it. In a situation where you are stuck waiting for a returned phone call or email, and you have other billable work that you cannot perform because of it, then that time is 100% billable to that client, even if you're just surfing the Internet.
Time: Demonstrate the time it takes to debug that process, and show how long it would take for you to restore a backup if something went wrong in production. Are they comfortable with the system being dead for an extra four hours at peak time while you sit on the phone and chase people?
If there are tasks you are contractually required to perform that are impossible due to your current connections, those need to be listed in writing, noting that if no further access is granted, then an addendum is necessary to the contract to relieve you of those duties. (They will then have to find somebody else to do them, which costs money.)
If the contract you have is an open-ended support agreement that pays the same weekly/monthly rate no matter how much time you spend, then you can only push from the angle that important requested tasks will slip while you complete the prior ones. You should also determine how much you will be losing if they don't budge, and be prepared to sever the contract if you're working many more hours then you are effectively being paid for. If you're working for free, then pull the plug. Spend that time not getting paid doing something productive, like finding paying customers.
If you are hourly, and they won't grant access, then at the very least, you can lose your frustration. Taking the extra time to perform your tasks - and billing for minute of it - is exactly what your customer wants. They may have policies that prevent them from granting you certain access, and should be made to understand and accept that additional costs are then involved for outsourced support. Later, when they need something quickly and are pressuring you for it quickly (such as restoring a production backup at an unfortunate time), you can assure them that you are working as fast as your arrangement allows, and you would be willing to revisit the situation once you put out the current fire.
Good luck.
-Eddie
Eddie Wuerch
MCM: SQL
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply