Showing posts with label sysadmin. Show all posts
Showing posts with label sysadmin. Show all posts

Thursday, June 11, 2009

User creation script

A consultant recently asked me for a copy of a script I created for our school to automate user creation. I thought it would be more useful for myself and the world if I just archived it here where I can always find it, and where other folks can use it (I find it much harder generally to find usable sample window code &c. than I do with linux).

These are my first (and hopefully last) scripts in virtual basic scripting. I'm putting them here to make it easier to share them, but these haven't really been prepared properly for sharing (I was simply working from examples until these worked). Obviously it would be worth setting these up with tweakable parameters up top at some future point.

Script for creating students


Create Users



This script creates student user accounts based on a CSV file with the following structure:

username, first, last, group, password


' Script to create student accounts
' Created by Tom Hinkle
' (or, if he's moved on,
'
' Requires file named students.csv in same directory with requisite information.
'
' File format is plain csv (no escaping) as follows:
'
' username, first, last, year-of-grad, password
'
' Note that year-of-grad is used for group names. We expect there to be an OU
' with the name of e.g. YOG2012 for each year-of-grad. Also, student folders
' are named by YOG, so we expect the students folder to contain a folder titled
' e.g. YOG2012

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objShell = CreateObject("Wscript.Shell")
upnSuffix = "cpcs.com"
Set objRootDSE = GetObject("LDAP://rootDSE")

dim fs,objTextFile
set fs=CreateObject("Scripting.FileSystemObject")
dim arrStr
set objTextFile = fs.OpenTextFile("students.csv")

Do while NOT objTextFile.AtEndOfStream
arrStr = split(objTextFile.ReadLine,",")
givenName = arrStr(1)
lastName = arrStr(2)
sn = lastName
cn = givenName & " " & lastName
OU = "YOG" & arrStr(3)
samAccountName = arrStr(0)
' Specify the NetBIOS name of the domain.
strNetBIOSDomain = "cpcs"
userPrincipalName = samAccountName & "@" & upnSuffix
homedir = "\\mms1.cpcs.com\students\" & OU & "\" & samAccountName
groupname = "LDAP://ou=" & OU & ",ou=Student,DC=CPCS,DC=com"

Set objContainer = GetObject(groupname)
Set objUser = objContainer.Create("User", "cn=" & cn)
objUser.Put "sAMAccountName", samAccountName
objUser.Put "userPrincipalName", userPrincipalName
objUser.Put "sn", sn
objUser.Put "givenName", givenName
objUser.Put "displayName", givenName & " " & sn
objUser.Put "userAccountControl", 512
objUser.Put "homeDirectory", homedir
objUser.Put "homeDrive", "H"
objUser.Put "scriptPath", "SLogon.bat"

On Error Resume Next
objUser.SetInfo
If (Err.Number 0) Then
Wscript.Echo "Unable to create " & samAccountName
End If
'On Error GoTo 0


objUser.SetInfo
objUser.SetPassword arrStr(4)
objUser.SetInfo



' Create folder, based on:
' http://www.eggheadcafe.com/software/aspnet/30289055/modifying-user-home-direc.aspx


If (objFSO.FolderExists(homedir) = False) Then
' Create folder.
On Error Resume Next
objFSO.CreateFolder homedir
If (Err.Number 0) Then
Wscript.Echo "Unable to create home directory for " & strSAM
End If
On Error GoTo 0
End If
If (objFSO.FolderExists(homedir) = True) Then
' Assign permissions to home directory.
intRunError = objShell.Run("%COMSPEC% /c echo Y| cacls " _
& homedir & " /T /E /C /G " & strNetBIOSDomain _
& "\" & samAccountName& ":F", 2, True)
If (intRunError 0) Then
Wscript.Echo "Unable to assign permissions for " & samAccountName
End If
End If
Loop
objTextFile.Close
set objTextFile = Nothing
set fs = Nothing
wscript.Echo("When you are done, you will want to go into active directory, highlight the new users manually, and add them to the group Students. You'll also need to disallow changing the password. Sorry I didn't get this done programmatically, but it's relatively simple to do manually")

Tuesday, December 9, 2008

Do real people actually use Windows Server?

Tonight I got one of many tech e-mails I get at school. In this case, the issue was related to a printer being down -- actually, a number of printers. If enough printers fail, it's a high priority issue, because it means teachers and students walking long distances to get print outs, and that's a lot of lost time at school (students may be thankful for the exercise and chance to socialize, but that's not really what we're aiming for).

Anyway, I decided it would be worthwhile to go into the server remotely and see what I could about the condition of the printers, so I could prioritize how important it was to get to fixing these printers soon. But the server is a Windows 2003 server. Our standard way of accessing it is over VNC or RDP, both of which can be really slow in the wrong conditions.

I've been waiting a good 30 seconds to get a response to each click remotely, which makes my "quick check" not so quick. This raises the question: why on God's green earth am I "clicking" anything?

There are lots of reasons why it doesn't make sense for a server to run a GUI. Among them is this: it's incredibly inefficient to transmit a picture of a whole desktop, and mouse events, etc., just to find out some basic information. If this thing were simply a *nix commandline, a 1200 baud modem would have sufficed to complete my inquiry in a few minutes. As it is, I'm giving up after a half hour (for what it's worth, I've been doing other things while I wait for responses from RDP). Do real people use this crap?

More and more I've been missing the commandline as I have to do admin work. I know that clicking is (theoretically) faster than typing commands, but between the ease of doing things remotely (I've spent hours programming on a remote system in emacs without noticing any difference from working locally) and the scriptability inherent in the commandline, I'm finding it hard to believe that people who administer machines for a living could ever do without a decent shell as their base of operations.

(Note: I know windows has a command prompt, but it's a pale shadow of bash, and as far as I know out of the box Windows Server does not have an ssh server enabled)

Wednesday, August 20, 2008

Sysadmins are not programmers

In my new life as a technology liason/sometimes sysadmin, I've had occasion to watch a Windows Systems Administrator at work, and to marvel at the ways in which the mind of such a person is not the same as the mind of a programmer. This is, to me, rather shocking: after all, the great thing about computers is that they're programmable, right? So someone who spends their lives working with computers... well, you'd expect them to know how to automate things.

I've always assumed that being a computer type means that you follow a very simple axiom: never repeat manually what could be done by a program for you.

In other words, automate the automatable, whenever possible, and, when it's not possible, whine like hell.

It turns out that our SysAdmin consultant does not think this way. Or perhaps it's simply that his definition of "possible" is extremely limited. At any rate, as a result of his ignorance in this matter, I've been reading up on scripting, trying to get myself the requisite literacy in Windows programming that, staggeringly, the Windows expert lacks. In this case, I have a very simple, very tedious task to do:

1. Collect a list of student users from our online student information database.
2. Create Active Directory accounts for those students that don't already have accounts.
3. Delete Active Directory student accounts for students not on our list.

This is the kind of task that any lover of computers should refuse to believe must be done by hand. (Note that I also had to create google-based e-mail accounts for these people — that was a no-brainer because google is not designed by idiots (there's a defined csv file and all I have to do is massage the data into that format and upload it).)

Lo and behold, after much fruitless searching, I have at long last found instructions for creating Active Directory accounts from information in a spreadsheet (or, if they were more sane, a csv file) (hopefully that link will help future googlers).

As I began to read those instructions, though, I was struck by the following strange prose, which so confused me, and so revealed the weirdness of the category of "System Administrator", that I had to stop reading and write this blog post. Here goes:
System administrators, or so we are often told, are the last of the rugged individualists. System administrators don't use mice and dropdown lists; they type their commands at the command line. System administrators don't bother with graphical user interfaces; they like their data displayed in the command window. System administrators don't pull up to the drive-through window at a fast-food restaurant, they actually get out of the car and... well, okay, even rugged individualists have to draw the line somewhere. The point is, you can run a script by starting it from the command prompt and passing it a bunch of command-line arguments; in addition, you can output data to the command window or to a text file. What more could you possibly need?

The truth is, there are lots of times you don't need anything else. On the other hand, sometimes—just sometimes, mind you—system administrators look at applications like Microsoft® Excel and think about how nice it would be to harness some of the capabilities Excel for their own use. Consider, for example, the need to create a bunch of new user accounts in Microsoft® Active Directory®. Could you do that by passing command-line parameters to a script? Sure, if you don't mind typing in command strings similar to this:

cscript new_user.vbs /cn="Myer Ken" /sAMAccountName="kenmyer" /givenName="Ken" /SN="Myer"

Okay, maybe that's not such a good idea. But couldn't you read in all the information from a text file? You bet you could. Of course, the text file would have to look something like this:

"CN","sAMAccountName","givenName","SN"
"Myer Ken","kenmyer","Ken","Myer"
"Jones TiAnna","TiAnnajones","TiAnna","Jones"
"Smith Ben","Bensmith","Ben","Smith"

That works, too, but good luck getting your HR department to supply you with a text file that looks like that. Can you use these techniques? If you want to. But think about how easy it would be for your HR department (or whoever) to type all this information in Excel; in fact, there's a good chance that's what they already do. Yes, Excel is a graphical utility, and, yes, you're a rugged individualist, but just this once, wouldn't it be nice to be able to take an Excel spreadsheet, run a script against it, and then use the information gleaned from the spreadsheet to create a whole bunch of user accounts, all in one fell swoop?

Okay, sure, not for you. But maybe you have a friend who isn't as rugged an individualist as you are. If so, tell your friend that he or she is in luck. This month we're going to tell you—um, we're going to tell them how to use a script to read data directly from an Excel spreadsheet, and then use that data to create a bunch of new user accounts in Active Directory. And then next month we'll show them how to go the opposite route: How to grab data out of Active Directory (or some other location) and display it in a nicely-formatted spreadsheet. And listen: If you decide to try these scripts, we promise not to tell your fellow system administrators. Promise

Ok, let's look at the crazy assumptions in the above:
  1. The point of the commandline is that you can do things with lots of parameters, which shows you're knowledgable.
    Actually, the point is that you can chain various commands together, and save useful combinations thereof in scripts. No one prefers typing long chains of obscure switches to pressing a few buttons; it's just that there's no way to program button-presses, so programmers prefer the commandline. It appears that sysadmins (as imagined by the above prose) try to imitate programmers by typing everything into a commandline, but don't actually understand it).
  2. A CSV text file is scary
    WTF? Is there any decent programming language that doesn't have simple libraries for handling CSV files?
  3. An Excel file is different from a csv file
    Again, WTF? Is there any person sufficiently computer literate to be reading this document who couldn't turn a given excel file into a csv file easily (Save As...)? And is there any HR department that could be trusted to get column headers etc. exactly right so you could run a script using their Excel file? Or is it actually true that all the crap excel adds to data to make the HR department happy (like formatting, for example) just gets in the way of the programmer, which is why you'd convert to CSV in the first place. I assume in this example we'll massage it into a predetermined format of Excel file instead, but if that's the case, there's really no difference between the Excel solution and the CSV solution.
  4. Rugged individualists wouldn't run scripts against spreadsheets
    Huh? I frankly can't imagine how any thinking person (and I assume these straw-man rugged individualists would style themselves thinking people) could possibly consider creating users doing anything other than running a script against something like a spreadsheet (assuming, that is, that one is copying a list of users from elsewhere, such as HR).

Of course the ultimate WTF is that this functionality isn't built into AD at a more basic level.
Anyway, I'll be reading the rest of the article soon. The odd thing about the article is that it seems to posit a commandline-using sysadmin in opposition to someone with a modicum of programming knowledge. And that, I must say, is very strange.

Saturday, August 9, 2008

Grrr... I hate closed source software

So in my new life as a tech administrator, I've gotten to play with OS X server and client machines. It turns out that OSX includes more or less the equivalent of Norton Ghost for free — that's a good thing. Our school hadn't configured or used this functionality in the past — that's a bad thing. Enter me to save the day!

Anyway, long story short, our previous tech guy had upgraded our server to 10.5 in order to fix some now-forgotten-about bug (grrr #1: paying to get upgrades that are really bugfixes). So, long story short, after a long time today setting up an image and setting up the server to use it, I had a problem: for some reason Mac's System Image program wasn't seeing my source disk as a valid image. I couldn't figure out what was going on for the longest time, until finally on Mac's website I discovered it: with the 10.5 version of the System Image program, you can only create images of System 10.5 and later. Our client machines all have 10.4.x on them.

Grrrr.

It's funny what you end up taking for granted in the open source world I'd been living in. Here are the things that would normally be unimaginable:
#1. That I can't update without making a big expenditure (and in this case, it would not just be one new client license but many)
#2. That I can't downgrade if an updated piece of software isn't any good (i.e. I can't get or run the 10.4 System Image program on my 10.5 server).

To solve this, I'll have to downgrade everything to the 10.4 server and hope that whatever bug bugged our last tech guy won't affect our new environment.

It's also quite puzzling to me that the System Image software cares about what kind of volume it's installing. I'd think with the base infrastructure in place, you'd be able to distribute images of any kind -- Window, Linux, Mac, what have you. I can understand that their might be some value-added stuff the System Image software can do that's specific to the OS, but it seems strange that they couldn't support at least a base functionality for any old system disk.