"net rpc vampire" is great but a Windows -> Samba migration is still complex 
enough that the system admin needs to fine-tune things afterwards.  Also, when 
doing a migration, one might want to only migrate a subset of users, or perform 
some conversions on the user information.

So I'd like to be able to do everything "net rpc vampire" does with command-line 
utilities - that way, instead of running "net rpc vampire", I could run "net rpc 
samdump", and use the output of that to enter the data that I want for the new 
Samba domain.  The "pdbedit" command looks like a good candidate for these
features. It would need options to add / manipulate:

* password hash string (i.e. accepts the encrypted password rather than the
cleartext password)

* Unix username of user

Another "nice to have" would be an option to "net rpc vampire" to print out the 
commands it would run to import the users rather than actually doing it. The 
printout would consist of the calls to the add user/group/machine scripts, and 
calls to pdbedit to create the users in the Samba backend.  The script output
could then be taken to another machine for testing, and edited as needed for
whatever the admin wants.

One thing I found during my testing for a Samba migration was that you have to 
test a LOT.  I must have run "net rpc vampire" 20 times trying to get things 
right, and each time I had to manually remove the Unix users and groups that
had been added on the previous run.  And this was for a domain with only six
users.

I would have preferred that my test machine be on a totally isolated network, 
but because I needed to re-run the vampire all the time, I had to have the
test machine on the same network as the Windows server and risk having active
users discovering my test box and trying to use it.  I could get away with that
in this instance, but I've worked in places where doing testing on the 
production network would be highly frowned upon.

If we want to make it easy to toss your Windows domain controllor into
the trash can, "net rpc vampire" needs to be more flexible and I think script 
output as described above is the way to go.