Mass importing users with Powershell

I've got a bit of a love-hate relationship with Powershell, but in this case it's turned into a bit of love. Importing users with Powershell is relatively easy to do when combined with ActiveRoles Management Shell for Active Directory, from Quest, which adds a handful of rather useful functions. PSCX supposedly has something similar, but I'm obviously missing them completely.

  1. Get someone to provide a spreadsheet with all users that they want for their new install (or export from an existing AD using CSVDE)
  2. Fiddle with the file, remove any crap you don't want, add anything you might, and convert to a CSV. For a new install we tend to set the inital password to something based around the user's name (which you can automate creating with an Excel formula). My finished format is something like this: givenname,middlename,surname,company,displayname,samaccountname,password
  3. Install Quest's ARM, and fire up the shell that it adds in your start menu
  4. Now it's simply a case of running the following, replacing my.domain/Path/To/OU/Users with your actual domain and the path to where you want the users placed (you can, obviously, make this part of the CSV, if you want)import-csv C:\Path\To\Users.csv | foreach-object { New-QADUser -FirstName $_.givenname ` -LastName $_.surname ` -SamAccountName $_.samaccountname ` -ParentContainer my.domain/Path/To/OU/Users ` -displayname $_.displayname ` -name $_.displayname ` | ` Set-QADUser -UserPassword $_.password | Enable-QADUser }
  5. Grab yourself a cuppa, or a beer, and tell the boss that you've been slaving all night (optional, of course)

Just to add an SBS 2008 twist to it, if you create your users in this manner you'll find that they show up in Active Directory Users and Computers, but not the SBS Console. The reason for this a special attribute on the object which doesn't get set. There's a nice article over at the SBS Blog which explains it for groups, but it's also applicable for users.

What it doesn't tell you is that for users, you can simply head into the SBS Console > Users, run the Change User Role for Accounts wizard, select Standard User, select your users (you'll need to select the checkbox to show all users), and then let it do it's magic. It'll setup your users Exchange mailboxes and shared folders in a jiffy.

SBS 2008 Shared & RedirectedFolders paths

By default Windows SBS 2008 has 2 shares setup - RedirectedFolders and UserShares, along with the various bits and bobs in the group policy to get it to work. Sadly they've placed the actual directories in the root of C:\. I don't like that. I'm fussy about file placement and it would be nice to move it to where we usually have the files (and have done since SBS 2000); D:\Data\..., which brings things into line with our standard setup that we tend to use at work.

Now you can just simply de-share the original directories, and move them to whereever you want. However this has the downside of causing issues (recreating the folders) if you create user accounts with the SBS 2008 console (since it also creates the various redirected folders for the user, and I know that several of our customers will be using this console).

Luckily there is provision to move these folders to another location. If you use the console you'll see that you can simply move it from drive to drive. However, if you delve into the registry you can see that 2 magic keys get created, which if you manually alter allows you to effectively place the directories where ever you like.

If you browse to
HLKM\SOFTWARE\Microsoft\SmallBusinessServer\Storage
You'll find that the following entries will either exist, or need to be created -
SharedRootPath SharedRootName FRRootPath FRShareName

*RootPath specifies the location for the user shared and redirected folders, where as the *ShareName specify the actual name of the shares themselves. Handy.

I'm all for documentation and howtos, but...

Does the world really need multiple tutorials and howtos, where the only difference is that the title says it affects different distros? Especially when those distros are closely related?

Specifically the one that set me off was seeing yet another PowerDNS item appear in the HowToForge feed. Thinking that bloglines was having trouble I went off to have a look, but sure enough there are at least 3 guides. One for Debian Etch, one for Ubuntu 8.10 (Intrepid) and one for CentOS 5.2. Now I can sort of understand the one for CentOS to a point. HowToForge is potentially for a market that doesn't know that their package manager is yum, or apt (although if you're trying to setup a DNS server, I might dispute that you're not ready if you don't know this), or where that specific distro puts various config files. On that front its very useful not to clutter one big howto with lots of "and", "or"'s.

However, Debian and Ubuntu are pretty closely related, and from a quick scan I honestly can't see the difference between the instructions other than the title. Granted I don't know the back end behind HowToForge, or it's policies, but surely it's possible to assign something to multiple distros?

I'm not specifically having a go at the person writing these documents, and this is why I've not linked to the articles. These people do an exceptionally important job, one of which is largely thankless.

So I'd like to say thank you to all the documentation writers. But may you could make your lives a little easier?

Uptime monitoring, using Munin, on Linux

Since I didn't come across an existing plugin after a quick google, and nor is there one in the official Munin repository that works on my Debian installations, I thought I'd post my implementation. It's exceptionally simple, however it might save someone 10 seconds of research and coding in the future. #!/usr/bin/perl if ($ARGV[0] and $ARGV[0] eq "config") { print "graph_args --base 1000 -l 0\n"; print "graph_title Uptime in days\n"; print "graph_category system\n"; print "graph_vlabel uptime\n"; print "uptime.label days\n"; print "uptime.draw AREA\n"; exit 0; } $uptime = `uptime`; $uptime =~ /up (.*?) day/; $up = int($1); print "uptime.value $up\n";

Print margins off in Outlook 2003, when using a custom font

We had a bit of a weird one come in today. A customer, using a specific custom font, had found that HTML emails using this font would have the right hand side of the text missing, effectively cutting off part of the email, when printed. Forwarding the email to yourself would fix the issue, since a forwarded email is indented I pretty quickly figured it was down to margins.

Now I was aware before this that the IE engine was used to print documents from Outlook, but what I wasn't aware of was that the print/page settings in IE affect the print also. Turns out that the File > Page Settings, Margins need to match the ones in Outlook to reliably get everything output right (in some cases). If it's not already been set IE will default to using 0.75 inches, which in the UK comes out at 19.05 mm, where as Outlook appears to default to 130mm (its actually measured in cm in the GUI oddly - nothing like consistency gents!).

Glad as I was that this resolved the issue for them, I wasn't happy about the prospect of telling the users to manually change these settings. I'm very much a believer that users should use the system, and not be bothered about stupid things like this (plus I like playing sysadmin god and making stuff just happen, then telling the users it's "just magic"). Thankfully the settings are sensibly stored in the registry (and rather handily documented in KB236777), meaning that it was possible for us to distribute the fixed settings to our client's users via a quick registry import in the logon script (I chose to use HKCU, rather than HKLM for various reasons, but it is possible to apply per computer rather than per user). It would've been very much possible to also take care of this by creating an ADM(x) file and distributing it via GPO, however I chose to do it via the logon script for 2 reasons;

  1. Someone looking at the script in question can see my reference, in a comment, to the call ID
  2. It was just much quicker using a reg import \\path\to\file.reg