If, like me, you are on a neverending quest to click less and script more, you can solve the problem this way:

• Create the destination group, should it not exist.
• Find the source group’s DN:
  >dsquery group -samid sourcegroup
  "CN=sourcegroup,OU=Groups,DC=contoso,DC=com"

  “-samid” argument is the group name whose DN you’re looking for. You can use “*” as a wildcard.

• Ditto for the destination group:
  >dsquery group -samid destinationgroup
  "CN=destinationgroup,OU=Groups,DC=contoso,DC=com"</li>
• On with the copy itself:
  >dsget group "CN=sourcegroup,OU=Groups,DC=contoso,DC=com" -members -expand | dsmod group "CN=destinationgroup,OU=Groups,DC=contoso,DC=com" -addmbr -c
  dsmod succeeded:CN=destinationgroup,OU=Groups,DC=contoso,DC=com

  These are two commands: “dsget group” and “dsmod group“. Output from the first is piped to the second. “-members” causes the group members’ DNs to be listed on standard output (one by line, quoted). “-expand” makes dsget to recursively expand the sub-groups that sourcegroup may hold.
  Conversely, dsmod modifies destinationgroup adding members to it.
  Very cool, so far. The only caveat is that the “-c” switch doesn’t work as advertised. It should copy members over destinationgroup even if already exist, but it doesn’t. If you need to re-sync source and dest, delete source’s contents from dest.

Bonus note; here’s a quick way to discover a user’s DN given his username:

And here’s how to add the same “A” record (named “www”) to each of the zones created above.

As you may have guessed this is the typical scenario where you’ve got to re-create some external zones, on the internal DNS servers. That’s needed in order for the internal hosts to reach some server with the “public” DNS name, but the private IP.
For the sake of completeness, let me also mention that you could achieve the same effect by leaving DNS as it is, and configuring “loopback NAT”/”double NAT” on the router/firewall. E.g.: an internal Host wants to reach an internal Server, given it’s public hostname, mapped to a public IP address. It asks the (possibly internal) DNS to translate the name. DNS doesn’t know the zone, it forwards the query to an external DNS Server, obtaining a public IP address that it hands back to the Client. Since its address is non-local, while trying to talk with the Server, the Client sends packets to its default gateway (possibly the router/firewall). The firewall matches the server’s public IP addresses, substituting it with the right private one. It also changes the source IP, swapping the Client’s with the firewall’s LAN address. This way Client and Server are actually communicating through the firewall, even if they’re both internal hosts. And the Server can’t tell Client A from Client B since every connection to it comes from the firewall’s IP address. That’s the main reason why I prefer duplicating the public DNS zones on internal DNS servers, with private IP addresses: you avoid routing internal traffic through the firewall, and avoid NAT where there shouldn’t be any.

Scenario: saturday morning (after having crashed into bed at 4:00 a.m., btw), Customer calls. A virus hit the Company and one of the most annoying consequences of the outburst, is that every domain user account gets locked due to brute-force login attempts (as per the “Account Lockout Threshold” policy). While they run around cleaning PCs and fixing A/V installations¹, I’m asked for a method to quickly unlock the accounts.

I tend to carry out these kind of tasks “the Unix way”, using the available DOS prompt commands and a bit of VBScript.

• Start off by calling LDIFDE:
  ldifde -r "(objectclass=user)" -l sAMAccountName -m -f users.ldf

  LDIFDE exports/imports Active Directory data to/from properly formatted (LDIF) text files. I use it a lot. Ran as shown above, LDIFDE exports the objects of class “user” into a file named users.ldf . Of the many attributes an LDAP object bears, I tell LDIFDE to output just the “sAMAccountName” one. If I hadn’t specified any attribute, in the resulting file I’d have found duplicate DNs for the same user. That’s because of how the resulting LDIF file is described. Some A/D data is “incrementally” added to existing objects given their DN. I just picked sAMAccountName because every user has one and, also, to keep the file small.

• Then:
  findstr /I /b dn.*ou=service.users users.ldf > service_users.txt
  findstr /I /b dn.*cn=users users.ldf > normal_users.txt

  findstr is Microsoft’s “poor man version” of grep, supporting a subset of the regular expression everyone has or should’ve come to love. Here I’m using it to extract Distinguished Names from the LDIF (only the ones that lie in a given Organizational Unit), and saving them to the *_users.txt files. They will look like:

  dn: CN=squidauth,OU=Service Users,DC=contoso,DC=com
  dn: CN=exchangebackup,OU=Service Users,DC=contoso,DC=com
  dn: CN=ldap,OU=Service Users,DC=contoso,DC=com
  dn: CN=batchcopy,OU=Service Users,DC=contoso,DC=com
• Here’s the VBScript function to unlock an account given its DN:
  Sub unlockuser(userDN)
    Set objUser = GetObject ("LDAP://" & userDN)
    objUser.IsAccountLocked = False
    objUser.SetInfo
  End Sub

  We just need to transform findstr’s output, substituting the leading “dn: ” with “unlockuser” and enclosing in double quotes what follows. At the top of the new, transformed, file, we’ll copy/paste unlockuser subroutine definition. That’ll make our final script.

• How to carry out the transform? Using this VBS snippet; it processes its Standard Input line by line, and outputs the modifications on Standard Output, just like any Unix file filtering command.
  Set StdIn = WScript.StdIn
  Do While Not StdIn.AtEndOfStream
      line = stdin.readline
      line = right(line,len(line)-4)
      wscript.echo "unlockuser """ & line & """"
  Loop

  I saved it in a “dnfilter.vbs” file and used it this way:

  type service_users.txt | cscript /nologo dnfilter.vbs > unlock_service_users.vbs

  To obtain something like this:

  unlockuser "CN=squidauth,OU=Service Users,DC=contoso,DC=com"
  unlockuser "CN=exchangebackup,OU=Service Users,DC=contoso,DC=com"
  unlockuser "CN=ldap,OU=Service Users,DC=contoso,DC=com"
  unlockuser "CN=batchcopy,OU=Service Users,DC=contoso,DC=com"

As I said, add the unlockuser function at the top of unlock_service_users.vbs and you’ll have your bulk unlocking script.

This time I chose VBS over Perl, hoping that this post would be more “instructional”. Perl on Windows is not so common, while VBScript is the standard way to automate stuff on that O.S. (despite the language being incredibly clumsy and annoying¹).

As for the graph format, I chose to output Graphviz DOT format/language.

The script works this way:

• Find the current domain.
• Find all the Domain Controllers (AD objects of class nTDSDSA, see this) and the Site they’re in.
• For each DC/Site, select nTDSConnection objects in NTDS Settings. Of course this is done by means of LDAP queries over ADO, but the view we get is equivalent to what we’re seeing in Active Directory Sites and Services.
• Print the DOT graph on standard output: DCs, connections and sites. DCs in the same site will be clustered together.

To use it, first generate the graph’s definition:

Then use Graphviz’s tools to lay out the graph and turn it into an actual image. For optimal results, I suggest something like:

Here’s what showed up, in my test case:

And here’s the same Domain, after some treatment:

Such graphs may be useful from a Sysadmin point of view, but they’re quite ugly, honestly. I originally thought to use Graphviz to output “some” format, read it in Dia or similar diagram drawing software, and then fix the aesthetics. But Dia support (if it ever worked) has been dropped from Grapviz (December 10, 2009). Dia’s 0.97.1 tarball bears a “dot2dia.py” plugin, but I haven’t hacked it into working. Any other editable format known to Graphviz (e.g.: SVG) doesn’t support “connector” primitives meaning that arrows won’t stick to objects while you drag them around… I’ll follow up if I make some progress.