TechnoGist

gist (jst)# The central idea; the essence…

Archive for the ‘Get-QADUser’ tag

Getting Exchange 2003 Database Statistics

without comments

I routinely analyze Exchange 2003 stores. To do this I previously had written a VB script that dumps all the mailboxes on an Exchange 2003 server using the Exchange_Mailbox WMI class, but as this is a PowerShell article i hear you say “How does this help me?”.
I use PowerShell more and more I really enjoy the simplicity and power of the PowerShell cmdline. So I started to look into producing some clean one liners or small scripts to produce something similar to my large VB script solution.

Note: In all examples below just replace “Server” with an Exchange 2003 server name.

Getting all Exchange 2003 Mailboxes on a single server using WMI,

GWMI -NameSpace Root\MicrosoftExchangeV2 -Class Exchange_Mailbox -ComputerName $Server | Export-CSV "C:\Scripts\Mailboxes.csv" -NoTypeInformation

The next step is to start filtering the output to get detailed information on trouble spots, for example to look for any mailboxes that contain more than ’5000′ items.
To find these we use the ‘.totalItems’ property of the ‘Exchange_Mailbox’ class.

Getting all Exchange 2003 Mailboxes on a single server that have more than 5000 ‘Items’,

GWMI -NameSpace Root\MicrosoftExchangeV2 -Class Exchange_Mailbox -ComputerName $Server |  Where{$_.totalitems -gt '5000'} | Export-CSV "C:\Scripts\Mailboxes.csv" -NoTypeInformation

Another WMI ‘Exchange_Mailbox’ class property I use is the ‘.DateDiscoveredAbsentInDS’ this tells me the date the mailbox was disconnected/deleted from the User Object in AD. If for any reason you do not want the store to clean up these automatically you can script the purge of the mailboxes using VBScript or PowerShell. The below code will enable you to see the mailboxes that are ready to be purged but will take no action.

Getting all Exchange 2003 Mailboxes that have been deleted (disconnected from their AD User object) and are ready to be ‘Purged’ on a single server,

GWMI -NameSpace Root\MicrosoftExchangeV2 -Class Exchange_Mailbox -ComputerName $Server |  Where{$_.DateDiscoveredAbsentInDS -ne $NULL} | Export-CSV "C:\Scripts\Mailboxes.csv" -NoTypeInformation

Another part to the Exchange Mailbox is the counterpart attributes held in the User object. Some of these attributes are the status of the Mailbox, for example “Is the user over his/her set limits?” or “Is the account disabled in AD?”. To find out the answers here we need to interrogate the user object attribute values. To do this there are many methods depending upon the version of PowerShell you are using and if you have the Quest Management tools loaded. In the example below i am utilizing the Quest Management Tools.

Hope this helps.

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

Written by Paul Brice

May 26th, 2009 at 10:23 am

Quest Get-QADUser – All User Attributes

without comments

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.

Written by Paul Brice

April 28th, 2009 at 4:52 pm