TechnoGist

I came into a situation today where PowerShell again came to the rescue.
I needed a time and date for a mailbox move in the past. We performed these moves using ‘Exchange 2003 System Manager’ (ESM). Once the moves are completed ESM places a resultant .XML file in the profile of the logged on user in a “My Documents\Exchange Task Wizard Logs\” folder. Unfortunately this was over a month ago otherwise I could examine the Exchange system logs for the successful move EventID.

However using the PowerShell Select-String CmdLet I was able to scan all the resultant .XML files (Several hundred) in a matter of seconds for a “String” of the users ‘cn’ (Common Name). If found the Pipeline would output the text string where it found the “Search String” and also the file name and path of the file.

Using the creation date of the file I have an approximate date/time of the mailbox move.

1

Select-String "usercn" "\\ExchangeServer\c$\Documents and Settings\%UserProfile%\My Documents\Exchange Task Wizard Logs\*.xml" | Format-List *

Hope this helps.

All information is provided on an AS-IS basis, with no warranties and confers no rights.

This article is part of a series of articles on the Quest Active Roles Management Shell and the CmdLets that are included in that.

Previously:
Getting Started
Get-QADGroup

The Get-QADUser CmdLet from Quest Tools can be used to return attributes back from your AD directory on a specific user object and place them in the local memory cache. The object returned by the CmdLet contains a pre-defined set of attributes. You can view or modify this default attribute set using the Get- or Set-QADPSSnapinSettings CmdLet. You can also change the returned attribute set on the returned object on an Ad-Hoc basis by using the -ExcludedProperties and -IncludedProperties parameters with the Get-QADUser CmdLet. One final option is the -IncludeAllProperties parameter, with this you can return all attributes of the user object and access them through the returned object in the memory cache.

So Examples,

The default attributes accessible in the returned object can be found here on page 39 in the “Quest Active Roles Management Shell for AD” guide.

Or enter this at the command line(With the Quest snap-in loaded)

Get-QADUser -Name accountname | Get-Member -MemberType Properties

To obtain all available attributes for a user object in your AD directory using the -IncludeAllProperties parameter.

Get-QADUser -Name accountname -IncludeAllProperties | Get-Member -MemberType Properties

Note: The above command will include all properties available in your AD directory in the returned user object, however when outputting the results to the cmdline the default attribute set controlled by the Get- or Set-QADPSSnapinSettings will prevail.

To see all user object attribute values

Get-QADUser -Name accountname -IncludeAllProperties | Format-List *

Export them to a .csv file

Get-QADUser -Name accountname -IncludeAllProperties | Export-CSV "C:\Scripts\UserDump.csv"

Including all properties(attributes) when you do not need them can add time to your executing code. I find it wise to minimize the data being queried and returned back whenever possible.

Using the above examples you can start to complete more complex user object queries.

For Example:

I would like to search for a user based on their SMTP address (.mail attribute) and then retrieve their set mailbox limits. The SMTP address or mail attribute is a standard attribute we can filter on using the -Email parameter. See here o n page 34 of the “Quest Active Roles Management Shell for AD” guide. The required returned object attribute of .mDBUseDefaults, .mDBStorageQuota and .mDBOoverQuotaLimit are not attributes cached by default in the returned object. To gain these attributes you need to include them in the returned object and specify them in the output pipe.

Get-QADUser -Email 'user@domain.com' -IncludedProperties mDBUseDefaults','mDBStorageQuota','mDBOoverQuotaLimit' | Format-List name,displayname,mDBUseDefaults,mDBStorageQuota,mDBOoverQuotaLimit

From this you should get back all the details of the user object specified in the Format-List command.

Hope this helps.

All information is provided on an AS-IS basis, with no warranties and confers no rights.

In my previous blog entry “Getting Started” I went over downloading and installing the Quest AD Management shell, registering the snapins and running some basic commands using the Get-QADUser CmdLet.

Today I will be looking at the Get-QADGroup CmdLet.
This allows easy access to Active Directory “Group” objects.

As before open a PowerShell Shell window and add in your snapins.

add-pssnapin Quest.ActiveRoles.ADManagement

Getting the number of members in a group.

(Get-QADGroup "GroupName").members.count

Export out the members of a group to a formatted table including the name,displayname,mail(SMTP) and office for each member.

Function Get-MemberName()
{
Process
{
ForEach($Member In $_)
{
Get-QADUser –ObjectAttributes @{distinguishedName=$Member}
}
}
}
(Get-QADGroup "GroupName").members | Get-MemberName | Format-Table name,displayname,mail,office

I often have to clean up groups by looking for disabled users.
To do this you can just add the “accountisdisabled” property to the script above.

E.g.

(Get-QADGroup "GroupName").members | Get-MemberName | Format-Table name,displayname,mail,office,accountisdisabled

Export out the members of a group to a CSV file with all properties.

Function Get-MemberName()
{
Process
{
ForEach($Member In $_)
{
Get-QADUser –ObjectAttributes @{distinguishedName=$Member}
}
}
}
(Get-QADGroup "GroupName").members | Get-MemberName | Export-Csv "C:\GroupMembers.csv"

Above are some useful examples of using Quest AD CmdLets to enumerate Active Directory Group objects.

Hope this helps.

All information is provided on an AS-IS basis, with no warranties and confers no rights.

Until now I have always used ADSI and LDAP to query Active Directory for object stored information.
I have been following Dimitry’s examples with the Quest AD PowerShell CmdLets and I thought it was about time I started to embrace them into my PowerShell scripts.

You can download the “ActiveRoles Management Shell for AD” Here.

Before running the Quest ActiveRoles Management Shell snapins I would recommend reading the “Requirements on Active Directory” section (p21) in the administration guide.

After you have installed the Quest ActiveRoles Management Shell you will have to register the PowerShell snapin at the PowerShell prompt.

Enter the command:

add-pssnapin Quest.ActiveRoles.ADManagement

Once you are ready to go and the Quest ActiveRoles Management Shell snapins are installed and registered you can get started with some basic commands.

For Example:

Getting the .displayName of your Active Directory account.

$User = Get-QADUser -Name "YourAccountName"
$User.DisplayName

Getting the Sam Account Name of your Active Directory account.

(Get-QADUSer -Name "YourAccountName").SamAccountName

Checking if a user account is disabled.

(Get-QADUSer -Name "UserAccount").AccountIsDisabled

Using the Get-QADUser with no previously specified connection details allows the Cmdlet to connect to any available domain controller with the credentials of the locally logged on user.

Next time I will start to go through mail enabled groups, their memberships and properties.

Hope this helps.

All information is provided on an AS-IS basis, with no warranties and confers no rights.

The public Beta for Exchange 2010 has finally been released.

Press Release
Microsoft Exchange 2010 Home Page
You Had me at EHLO: Presenting Exchange 2010

Watch the video announcement on the “You Had Me At EHLO” blog.

Here are some subjects covered.

1. They have pushed Exchange 2010 to have upwards of 50% further IO reduction according to Rajesh Jha the MS Exchange product VP over and above the projected 70% reduction in IO with Exchange 2007.
2. “Role Based Administration Control” -Ability to offload common administrative tasks to the user community.
3. Integrated Personal Archiving with Discovery.
4. Partial in cloud and partial on-premise Email service.

I am looking forward to looking at this version, especialy the RBAC, the consolidated API “Exchange Web Services” and the new functionality that is brought to the PowerShell shell!

Updated News and Information on the Exchange 2010 Beta.. Here

As I have been migrating over my scripts from VBScript to PowerShell I have had to convert over several scripts.
One example of this is a section of code that I use to pull data from Tables in SQL databases.
This code assumes you are using SQL authentication credentials.

#Authentication Strings
$account = “user”
$pw = “password”
$table = “table or view”
$db = “sql database”
$server = “sql server”

# Specify SQL Query
$SqlQuery = “Select * From $table”

# Create SQL connection object
$SqlConnection = New-Object System.Data.SqlClient.SqlConnection

#Set the ‘Connection String’ property
$SqlConnection.ConnectionString = “Server = $server; Database = $db;user = $account; password = $pw”

# Create SQLCommand object
$SqlCmd = New-Object System.Data.SqlClient.SqlCommand

#Set SQLCommand Text property (SQL Query)
$SqlCmd.CommandText = $SqlQuery

#Set the Connection property
$SqlCmd.Connection = $SqlConnection

#Create SQL Adapter repository
$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter

#Run SQL Connection
$SqlAdapter.SelectCommand = $SqlCmd

#Create SQL DateSet object
$DataSet = New-Object System.Data.DataSet

#Populate $DataSet with Connection results
$nRecs = $SqlAdapter.Fill($DataSet)
$nRecs | Out-Null

#Populate Table object with required Table
$ objTable = $DataSet.Tables[0]

#Parse through the rows
ForEach($objRow In $objTable)
{
#Echo Column Names
Write-Host $objRow.column
}

In the above code you will need to supply replacements for, $account, $pw, $table, $db and $server. Depending on the database you are connecting to and the structure of the table you will want to modify the contents of $SqlQuery (SQL query string) and the $objRow.column would need to be changed to a valid column name for the table you are querying against.

I hope this helps.

All information is provided on an AS-IS basis, with no warranties and confers no rights.

In Active Directory a user object can hold multiple “Proxy” addresses.
Using ADSI and LDAP the PowerShell script below enumerates all .proxyaddresses from a specific Active Directory user object.

This scripting technique can be used to get any Active Directory user object attributes.

All information is provided on an AS-IS basis, with no warranties and confers no rights.

I routinely have to populate Active Directory Email distribution lists from lists of employee full names. These list usually contain the “.displayName” of the user. A quick way to resolve this is to convert the “.displayName” of the user into the users common name or “.cn” attribute and cut/paste them into the distribution lists “Members” box. I put the list of users display names into a C:\Scripts\Users.txt file and the script will produce a list of .cn attribute in the C:\Scripts\ConvertedUsers.txt file.

All information is provided on an AS-IS basis, with no warranties and confers no rights.

Many of the PowerShell scripts that I write are for Exchange 2003. To keep the scripts as dynamic as possible I like to enumerate my servers from AD. The server objects for Exchange are held in the Configuration partition of the AD Schema.

All information is provided on an AS-IS basis, with no warranties and confers no rights.