Update to Create-LabUsers!

Update to Create-LabUsers!


Sometimes, your mind just gets to thinking about stuff you could have done better.  Last night was one of those times.

I’d started building new lab environments for work, and decided to start pumping users into AD and syncing them to my test tenants.  I had an urgent item to test, so I hadn’t yet installed Exchange in my first lab.  I fired up Create-LabUsers and started receiving an error for mailnickname not being found.

D’oh!  I’d created the script in a lab that already had been prepped for Exchange (even though it didn’t have Exchange), so it had never dawned on me to even check for it.  So, I added a quick test of a AD schema to look for the mailnickname property before filling it out:

 $schema = [directoryservices.activedirectory.activedirectoryschema]::getcurrentschema()
 $ExchTest = $schema.FindClass("user").OptionalProperties | ? { $_.Name -match "mailNickname" }

But then, I got to thinking about some other things that didn’t work quite as well as I wanted to.  And then the updates started flowing.

Here’s a comprehensive list of everything I’ve changed this version:

  • Reduced output to console for errors and Write-Progress updates.  I decided that dumping everything to screen was messy-looking, so I replaced all of the console output for informational/status messages with Write-Progress.  Everything still shows up in the logs, though.
  • Updated logic for sending emails.  I had an idea originally in my head for generating messages, but somehow got lost along the way.  And, when I ended up implementing the InflateMailboxes parameter, I looped at the wrong point, so every time you’d adjust the number of messages you wanted to fill mailboxes with, the amount of mail you’d send would grow exponentially.  Ick.  So, I fixed it.  It now counts at the total number of messages being sent, and now defaults to 500 with random binary attachments.
  • Performed check for mailnickname attribute before specifying it in user creation.
  • Updated logic for nested group membership processing to resolve issue if CreateGroups was run without any users existing in the OU path.  I was testing each feature individually, and discovered this one after I deleted the entire container structure and just ran CreateGroups without having created any users.  In the original code, nested group membership relied on discovering user job titles, grouping those together, and then rolling up into top-level groups. if no users were previously created, this step would error out with a null index message.  Oops.
  • Updated mailbox and calendar delegate permissions assignment to only select up to 15 mailboxes per OU to reduce the amount of time to complete.  When I originally implemented the mailbox and calendar permissions functions, I just queried each OU and set random permissions.  The problem was, if you eneded up creating tens of thousands of users (or running the script in several batches), you’d take an increasingly longer amount of time to generate ACLs.  I settled on a low number, since in a real production enviornment, most people don’t have delegates anyway.  So, it feels a pinch more lifelike.
  • General code cleanup.  There were some old commented-out functions and lines that I’ve removed, so it looks better.

Here’s a the nifty new view:

You can start creating you own lab at http://aka.ms/CreateLabUsers.

Published by Aaron Guilmette

Helping companies conquer inferior technology since 1997. I spend my time developing and implementing technology solutions so people can spend less time with technology. Specialties: Active Directory and Exchange consulting and deployment, Virtualization, Disaster Recovery, Office 365, datacenter migration/consolidation, cheese.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.