This is the kind of thing why you hire in admins with scripting capabilities or encourage your admins to learn how to script or set up a tool group to write scripts for everyone.
A long time ago in a galaxy far far away I worked at a very large company on NT4 stuff. We used SMS but found it to be so crappy (It was like SMS 1.2 or something like that) that it could barely properly deliver a menu pick so we sat down for a month and wrote a software delivery system for NT from perl. It wasn't completely original, the client integration group had done something similar with I think C for Win9x. We just took the idea and expanded it to NT. Basically the perl script would read a null share read only file share to find out what needed to be delivered to a specific machine and then went to another share with a copy of the software package to install and ran the install batch file (this could easily be keyed by AD/AM or AD attributes now now to keep the info together, didn't have that option with NT4). You could compile this and make it into a service or you could use srvany to make it run as a perl script directly as a service. The package was a simple batch file that had all the commands that needed to be run and it logged everything to another share on the server so it was all recorded. There was a simple web interface to queue up jobs, it simply listed what could be deployed and listed which machines to deploy too, you could also manually type in the machine. In the end I believe we could specify it by user as well if we wanted. The packages themselves were usually broken out of their native install packets and broken into reg updates and file updates, however we had several that were native installshield packages and we had made a few installshield packages as well. When the request went into the web system, it would record that it was queued and would warn the software inventory system so we could track it later that way too. It ran in whatever context the service ran in or it could be fired as a logon script as well to run as users. If you don't want to pay for something because it sucks or because it just doesn't do things in a way that suits your model, writing a simple scripted tool to do this stuff usually isn't rocket science. It is much easier to build a simple system for yourself than it is to build a generic system that would work for anyone. So people who look at say an SMS and say, we couldn't build something like that are right. You can't. But you could build something you can use that will be tailored to you and probably more to your liking. You just have to continue to support it. That support part scares people too. However I have written many scripts back in the 90's that are still used daily today. I just chatted with some friends about some scripts I wrote back in 2001 or so that were supposed to be short term scripts until a better solution came along and they have run so well, they became the solution. If you aren't a scripter, become one. It can really help. I recommend perl, it hasn't done me wrong. The difficult it makes easy, the impossible it simply makes difficult. Oh, another thing to look at is CPAU on www.joeware.net. It is like runas but will let you encode (and I mean encode, not encrypt) a JOB file with a userid and password so that you can run it in a logon script and get enhanced rights. Make sure you read up on the use of the -profile switch when using it that way. It was designed to give you network credentials by default, I always hated typing /NETONLY in runas when I wrote it and one of the big reasons I wrote it. I got pinged by Novell some time ago because they wanted to list this tool in their useful tools for admins section of some web site. I said fine, have a nice day. It is one of the tools on my website which is probably one of the most downloaded but receives the least amount of press because it isn't "cool" and doesn't do AD stuff. I don't mind it a whole lot because again, the JOB file is encoded, not encrypted. I was once contacted by someone who said they cracked it but they really didn't. Another guy contacted me and said in a debugger he could see some info and I replied back... Of course you can. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harding, Devon Sent: Tuesday, July 19, 2005 9:10 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Logon script with Admin rights How can I run a batch file logon script to map a drive and install an application on a user's PC as an Administrator? I don't want to expose the password using 'run as' Devon Harding Windows Systems Engineer Southern Wine & Spirits - BSG 954-602-2469 - List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
