Archive for May, 2010

Check who can send email to a group

Today I wanted to get a list of people who had rights to send messages to a few distribution lists in our company. This information is not readily available in Outlook, but turned out to be very easy to retrieve using PowerShell – this is literally just a few attributes to retrieve from your Active Directory.

Here’s a sample output of my script:

PS:\> Get-DLRestriction "Worldwide Everyone"
Checking restrictions for Worldwide Everyone

The following users can send messages to this list:

Anne Smith
John Able

Members of this group can send messages to this list: Domain\Communicators) :

Susan Gallings
Terry Adams

Only authenticated users can send messages to this list.
External senders get blocked.

I’ve uploaded the script to poshcode, but for your convenience also posting it here:

function Get-DLRestriction {
  param([System.String]  $DLName  )

  "Checking restrictions for $DLName"

  $DL = Get-QADGroup $DLName `
      -IncludedProperties AuthOrig, UnauthOrig, dLMemRejectPerms,`
                      dLMemSubmitPerms, msExchRequireAuthToSendTo

  # we'll set this to true if we see a restriction
  $restricted = $false

  # if the group with such a name is found
  if ( $DL -ne $null ) { 
    if ( $DL.AuthOrig -ne $null ) { 
      $restricted = $true
      "`nThe following users can send messages to this list:"
      $DL.AuthOrig | Get-QADUser
    if ( $DL.UnauthOrig -ne $null ) { 
      $restricted = $true
      "`nAnyone BUT the following users can send messages to this list:"
      $DL.UnauthOrig | Get-QADUser
    if ( $DL.dLMemSubmitPerms -ne $null ) { 
      $restricted = $true
      "`nMembers of this group can send messages to this list: $($DL.dLMemSubmitPerms | Get-QADGroup)) :"
      Get-QADGroupMember $DL.dLMemSubmitPerms
    if ( $DL.dLMemRejectPerms -ne $null ) { 
      $restricted = $true
      "`nAnyone BUT members of this group can send messages to this list: $($DL.dLMemRejectPerms | Get-QADGroup)) :"
      Get-QADGroupMember $DL.dLMemRejectPerms
    if ( $DL.msExchRequireAuthToSendTo ) { 
      $restricted = $true
      "`nOnly authenticated users can send messages to this list.`nExternal senders get blocked."
    if ( -not $restricted ) {
      "`nThis list is not restricted. Anyone can email it."
  } else {
    "`nDL $DLName not found."

Windows & AD Security Webcast

On June 17, Randy F. Smith from Ultimate Windows Security is holding a webinar on using PowerShell to ensure Active Directory and Windows Server security. The webcast is sponsored by Quest and free to attend.

Here’s the announcement I got from Randy:

Finding users accounts who haven’t logged on in X days is important but there’s no good way to do it in AD.  Yes Active Directory Users and Computers as the “days since last logon” query option but it doesn’t work right, doesn’t display last logon date/time and omits users how have never logged on at all.

Figuring out last logon date and time is complicated.  First, the lastlogon field isn’t displayed anywhere in Active Directory.  Second, that field is updated when you logon but only on the domain controller that authenticates you; the field is never replicated to other DCs.  If your domain is in Windows 2000 Mixed or Native mode, that means you have to query each domain controller for each user account. If your domain is in Windows 2003 higher modes, AD adds a new field called LastLogonTimeStamp which is replicated by default every 7 days.  This field isn’t displayed anywhere in AD either.

This is just one of several problems that have irked me for a decade and now these problems are solved with a new open source utility that I designed and Quest Software graciously implemented called the Windows Security PowerPack.  This is our gift to you for being such an awesome community; I’ll show you how to get the PowerPack and how to use it in my upcoming webinar.

In fact, in this webinar, I will show you 4 Windows/AD security problems that desperately need a solution and then demonstrate how this PowerPack solves them.

PowerPacks are tool sets that snap into PowerGUI which is an open source extensible graphical administrative console for managing systems based on Windows PowerShell.  PowerShell is a command-line shell and scripting language designed especially for system administration.

This new PowerPack is just one out of a world of free PowerPacks that solve all kinds of admin problems without coding or even scripting.

Register now for this webinar.  It’s more than real training for free (TM) – this one is real software for free.

Click here to register


Title: Finding Dormant User Accounts in Active Directory
Date: Thursday, June 17, 2010 11:00:00 AM EDT

Space is limited.
Reserve your Webinar seat now at:

Need CPE credit for this or any other webinar? Just visit, click on the Webinars section, and then the link for CPE credit transcript.

Thanks as always for reading and best wishes on security,
Randy Franklin Smith

PowerShell for acceptance testing

PowerShell with its .NET integration and more and more products/platforms shipping with native PowerShell cmdlets is a great tool for automated testing. (I even posted a sample PowerPack helping organize tests in PowerGUI a few years ago.)

We at Quest Software are using PowerShell a lot for our software development and testing. Our SharePoint management team is on the cutting edge and extended acceptance testing Fitnesse framework to PowerShell.

But wait, now it gets really cool: they have open-sourced the PowerShell Fitnesse framework – PowerSlim at codeplex for everyone to download, use, modify, and update!

Read more about PowerSlim in Konstantin’s blog here.

Power Corrupts

Turns out that there is still media which has print material not available online, so quoting a recent article from UK’s PC Pro, rather than linking to it.

In a recent print edition of the magazin, the “Server Room” column entitled, “Power Corrupts,” includes a quick review of PowerGUI (both graphical user interface and script editor/debugger.)

Here’s what David Moss writes in conclusion, “I’m impressed with Power GUI and its associated tools; it not only does what you want it to do, but it shows you just how it does it and lets you get your hands dirty in a safe environment.”

This is a great point. We designed PowerGUI to be WYSIWYG (What You See Is What You Get) for IT professionals, and it is great to see people taking advantage of this open, yet intuitive approach.

Fly to UK and buy the magazin if you want to read the whole story. 😉

The best of both worlds

GUI or command-line? Alan Renouf (aka Virtu-Al) reflects on this dilemma in this fascinating blog post.

He looks at the advantages of GUI (intuitive, familiar, easy to learn) and command-line/scripting (powerful, flexible, well-suited for bulk operations), and how he is using PowerGUI (or, as a lot of virtulization folks know it – VESI) to get the best of both worlds:

Alan created a very popular VMware Community PowerPack (which had more than 8 thousand downloads already!) and is a very successful virtualization consultant so his views (and tools ;)) are always worth checking out.

Read Alan’s post here.

Storing PowerGUI add-on configuration

Quite often PowerPacks need to store some configuration/user preferences: like domain name, of virtual machine host, or SharePoint server being managed. I had a few folks asking me how I do it in my packs so I wanted to share the code samples I use. Basically, what I do boils down to:

  • Keeping all configuration parameters in one dictionary structure ($parameters in the code sample below), and
  • Saving this parameters data structure as an xml file into PowerGUI’s user profile folder.

The code below is quite straight-forward and self explanatory so hopefully it will help you get started:

# Assign unique folder and config names
# This would sore data in:
# C:\Users\username\AppData\Roaming\Quest Software\PowerGUI\MyAddOn.Config.xml
# or in Pro version:
# C:\Users\username\AppData\Roaming\Quest Software\PowerGUI Pro\MyAddOn.Config.xml

# For PowerGUI, it makes sense to store data in PowerGUI config folder
# For non-PowerGUI solutions, you would probably create a subfolder in
# $env:appdata

$FolderName = $Host.PrivateData.UserAppData
$ConfigName = "MyAddOn.Config.xml"

# keep all add-on parameters in a map
$parameters = @{}

# read parameters

if ( Test-Path -Path "$FolderName\$ConfigName") {
  $parameters = Import-Clixml -Path "$FolderName\$ConfigName"

  # now you can use them, e.g.
  "Hello, " + $parameters['User name']
  "Isn't your birthday on " + $parameters['Birthday'] + "?"
} else {

# Your add-on specific code, to get user preferences
$parameters['User name'] = Read-Host "I don't know you yet. What's your name?"
$parameters['Birthday'] = Read-Host "And your birthday is?.."

# store parameters
$parameters | Export-Clixml -Path "$FolderName\$ConfigName"

Depending on your add-on/powerpack, you might tweek it a little to have some of the variables declared as global (e.g. $global:parameters) and maybe wrapped some code into functions. Leave your comments or ask questions at the forums at if you need any help.

[UPDATE] Tweaked the script based on Oleg’s tip on locating PowerGUI configuration folder.
[UPDATE 2] Updated the text and the script based on Harley’s feedback.

List all workstations in the domain

Here’s another quick oneliner I had to create for someone today and wanted to share with you:

Get-QADComputer -ComputerRole member -SizeLimit 0 -OSName 'Windows XP*', 'Windows 2000 Professional', 'Windows 7*', 'Windows Vista*'

The initial one-liner the customer was using was retrieving all Member computers but then using Where to filter by $_.operatingsystem whatever did not have Server in the name. This took longer (because Where is filtering on the client side after all objects are already retrieved) and resulted in extra computers being reported such as non-Windows storage systems.

Using cmdlet parameters makes sure that filtering is done during the object retrieval which is more efficient. And, as you can see, OSName parameter – as most parameters in QAD cmdlets – supports multiple values.

Depending on your environment you might want to modify the OS list to include Windows 8 or Mac OS 😉

If you want to get full list of operating systems in use in your company you would probably execute something like:

Get-QADComputer -SizeLimit 0 | group operatingsystem | sort Count -Descending

Hope this helps!

My Recent Tweets


The posts on this blog are provided “as is” with no warranties and confer no rights. The opinions expressed on this site are mine and mine alone, and do not necessarily represent those of my employer - WSO2 or anyone else for that matter. All trademarks acknowledged.

© 2007-2014 Dmitry Sotnikov

May 2010

%d bloggers like this: