|
the long... PC Admin is an attempt at establishing a
framework for all the misc perl, wsh/vb and even java scripts that a
netadmin writes, borrows or inherits for the remote management of NT/Win2K
workstations in a large (2000+) NT domain. It started as a short web demo of WakeOnLan because current staff thought that it required an expensive vendor solution. It turned out to be ridiculiously easy (Ken Yap's mp-form.pl) which then generated a response "well so what?" This is not a replacement for SMS, On, CA, Support.Com, Tivoli, UM, PQ DeployCenter or alphabet soup. It is a framework for your tool kit of perl scripts, little odds and ends you wrote to fix a registry entry, poll to find out who is mapping that printer, wacked to all the admin$ shares to search for bad host files, add or remove local admins .. in short all the trashy scripts that will not scale, become sort of scalable. The core problem of deskside work is the onessie twoizzie nature of tickets. They are unique and sometimes not really unique but you pretend they are. You may have a scripted solution for it but can't apply it ... alhhh hell just walk over and do it. She pretty cute anyway. When I was doing it, i made the visit, the call, why write a script? Now i watch others do it, and look at the $50-$100/hour meter ticking and ticking and ticking. My guys aren't building servers, monitoring servers, ...instead it's updating virus dat files?!?? Not so funny when you have to trim head count. So this is not the glory of a group policy template applied across your enterprise. It is a point to point solution, this pc needs that, or doesn't or things aren't as standard as architecture says they will be. Anyway if you're thru my verbage we can get to the core of the matter. We need to design a XML schema wrapper for all the scripts we collected willy-nilly over the years. I personally probably wrote maybe 10% of the scripts I use every day. The other 90% are adapted from somebody else's scripts. You might call it the MCSE's version of open source. One script writes to the console, but then nobody is around to read the console, so i hack in a logger. Some use parameter switches, some just an arguement count, some query the domain for a total list, so i hack in a long ini file parser blah blah blah. I'm a slob. No big deal with 50, 100 servers. But 2000 workstations which behave like servers is another matter. If you know WSH syntax, the tag file idea is a natural. I sort of want a tag for job list, logger, database, result status, config file, help manual etc etc etc and of course is it perl or java or wscript/cscript or tcl or python. Right now the add-job.asp code just creates the command line string...and each script needs a custom string. Not hard to do...but hell to maintain. In a unix shop, every admin maintains scripts, it is a natural part of the job. In a Microsoft NT shop, perl is some commie plot to cut payroll. So I have tried in vain for 3 years to get my fellow admins to use it. If I wrap it in a web interface they can't tell the difference... and it is click click click. So when i'm up for a headcount reduction, the next guy might have some ink at http://pcadmin.sourceforge.net Although I note minimal activity on sourceforge for the Microsoft MCSE school of thought, there is some. And since I can't get anyone else to look/design/use the interface at work...a couple of beers late at night and yet another sourceforge project is born. You will note many blank home pages for these late night ventures...and if i can't get cygwin ssh to login to the CVS here, this could be yet another one. I see the input for other developers/NetAdmins as 3 part. the Database Point the project at an existing database schema instead of reinventing another one. I've peeked at the CA TNG schema and cim objects make me go blind. The morass of WMI looks possible, but then why stick it into a database when you can do the real time poll? I am the maintainer/developer of a web based ASP script code help desk application talking to a mssql65 database using an ancient software artistry expert advisor database. Maybe 10% of the tables are used by the web application. Buried in the table design is an inventory, node table design matching the current user/ticket system. We need to track the scripts against the target pc's the same way that users and trouble tickets are tracked. So if i have a sql moment, i might try to float up a scalable pc/ticket/node table schema. Anyway any real db people out there? I've been tracking DCL and phpgroupware tts for a year for ideas...but if there aren't any contributions..we get a flat table of 2000 pc's... the Interface There is a huge amount of power in a properly designed interface. Phpgroupware has become a real groupware application instead of just another webcalendar hack. In the same vain, i have borrowed the asptoday web calendar example, graffed in the idea of scripts as tasks/jobs and maybe that will scale. Currently the core menu interface is a database display of the clients where you can query by hostname, macaddress, ip address or user id (from a WINS dump of the associated ip address for that user which i'll stick up on the CVS when i squash the last bug). Just the display of the mac addresses turns out to be extremely useful. I can enumurate all the thinkpad T20's on the network because the oui mac id fragment is searchable. But then the interface gets a little clunky building the list of target pc's for a script, because i don't have an associated database of what sp is current, i write and schedule a script to id the service pack, then dump to next list, then to the script to copy sp2 over, then the schedule for WOL, and psexec \\xxxx c:\w2ksp2\update -u -i -n etc etc etc.... ie) this ain't any better than the old way... Anyway if you don't like asp vbscript/perlscript/javascript which you can't do in dotnet anyway, by all means write the php stuff. get rid of my cheezziee icons, think up another interface besides data centric the Scripts I really don't image this to become the repository of scripts that http://cwashington.netreach.net has become, or tries to be. From my cvs tree you can see i have something like /pcadmin/scripts/shutdown/ for my shutdown script. Give your script a name, stick it in, insert into the scripts table database (currently mdb jet by the way in asptoday web example), and away you go. If you don't want to join CVS, just stick the script in the forum and i'll insert it. The xml wrapper idea might be off the wall, and months to settle on a parser, so like all NetAdmins, this is a "just do it" sort of thing. which is the lead in to the fine print... WOL is a mechanism for me to increase my test bed beyond the lab. Anyone who writes scripts knows there is a learning curve, and a maintanence line. The script that worked fine last year on NT4sp4, might die on sp6a. So a part of any deployment of a script is an initial sample. The guy in the next cube is not a valid tester. So a database of 2000 pc's with a history, might get you a sample of 20 (who are not VP's). And if your error rate is 5%...that is 1 pc log to track and fix. Deploy a script via login script or group policy for 2000 pc's and a 5% error rate means 100 calls to the helpdesk. Get in the habit of staged deployments, and test test test. The goal is a .1% error rate or 2 calls to the help desk when it becomes a global script. So if this sf project becomes another blank stale page, i will at least have a framework to test point to point. In 3 years of monitoring scripts I have never bombed a production server or domain controller with a script. The fear and lothing factor amoung other MCSE's on staff is not eliminated with a pretty interface. You have to know the script, and that is usually the author of the script. So it is unlikely that this application will ever scale to the front line helpdesk to schedule a job. Still why anyone would expect perfection from computers and software and people and their mix is beyond my understanding. So beware, if you don't know what a script is doing, don't do it. Wait maybe for a files package v1.0 by Sept if you don't want to check out via CVS. I am reluntant to make a package now, because I like many others download willy-nilly anything remotely interesting from sf. This code is rather unique in perlscript within a web page so if you don't have that it will look like perl gibberish. thanks for wading thru my rambling ivan 6/10/01 |
