IT tutorials
 
Applications Server
 

Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 5) - Server-side and client-side filters

12/1/2013 8:22:02 PM
- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

7. OPATH filters

OPATH is the basic syntax used for PowerShell queries. It is similar in concept to but uses different syntax from Lightweight Directory Access Protocol (LDAP) queries. Dynamic distribution groups also use OPATH queries to locate objects in Active Directory when the transport system builds addressee lists to deliver message addresses to these groups.

Some base guidelines about the syntax OPATH queries are as follows:

  • OPATH requires a hyphen before –and, –or, and –not operators.

  • Comparison operators include –eq (equal), –ne (not equal), –lt (less than), –gt (greater than), –like (like), –ilike, and –notlike. –Like and –notlike are wildcard string compares. –iLike and –inotlike are case-insensitive.

  • Filters should be expressed within braces; for example, {Office –eq ‘London’}.

8. Server-side and client-side filters

Windows PowerShell supports server-side and client-side filters. There’s a big difference in performance between the two types of filters, especially when you have to process more than a hundred objects. Client-side filters are the default. Any code that uses the Where cmdlet executes a client-side filter. Client-side filters request data from a server and then perform the filtering on the client. This is an effective approach if you only have 10 or 15 objects to process, but it obviously doesn’t scale too well as the number of objects increases.

Server-side filters have better scalability because the request for data forces the server to return a filtered data set to the client. Because Exchange servers often have to deal with tens of thousands of objects, a number of the Exchange cmdlets support server-side filters. If a cmdlet supports the –Filter parameter, it supports server-side filters. Usually, these are cmdlets that deal with objects that output large numbers, such as mail-enabled recipients or message queues. All the precanned filters generated for dynamic distribution groups, address lists, and email address policies use server-side filters.

As an example of server-side and client-side filtering in action, two methods are available to find all the mailboxes with “James” in their name, as demonstrated in these commands:

Get-Mailbox –Filter {Name –like '*James*'} –ResultSize 5000
Get-Mailbox –ResultSize 5000 | Where {$_.Name –like '*James*'}

On the surface, these two pieces of code seem reasonably similar, but they are very different in reality. The first difference is that the first code example uses a server-side filter, and the second uses a client-side filter. The second difference is that the two filter types can generate very different results because of the way the filters operate. If you omit the –ResultSize parameter, the same query is generated: Find all the mailboxes with a name that contains “James.” (The ResultSize parameter in the first example limits the total number of objects returned to 5,000.) However, if you time both queries, the server-side filter invariably executes faster than the client-side filter, largely because fewer data are transferred between server and client. To understand why the filters generate different results, you have to appreciate how the filters work:

  • The server-side filter returns the first 5,000 mailboxes it finds that include “James” in the mailbox name.

  • The client-side filter fetches data for the first 5,000 mailboxes and then applies the filter to find the mailboxes that include “James” in the mailbox name. However, the filter applies only to the set the client fetched and might not find all the mailboxes you actually want to discover.

Even though you ask the server-side filter to do more work (working with any reasonably sized set of mailboxes, the server-side filter will have to process significantly more data to find the first 5,000 mailboxes that match), it still executes faster. For example, when I executed similar commands within a very large Exchange organization (170,000 mailboxes), the server-side filter completed processing in 43 seconds, whereas the client-side filter completed in 81 seconds. The rule here is that the effect of server-side filtering gets better as the number of objects increases.

Inside Out PowerShell and memory limits

Another aspect to consider is that PowerShell cannot fetch and cache data on disk temporarily the way a database might. This is not an issue if you want to process only a few objects, but it can lead to memory issues if you attempt to process tens of thousands of mailboxes at one time, especially if you use client-side filters and want to pipe the output to another command. In this case, you ask PowerShell to find all the objects that match the specified filter, store the data in memory, process the data, and pipe the matching objects to the second command. Experience shows that these operations can cause PowerShell to complain that it is running out of memory. This is likely to be one of the growing pains through which all software goes and, apart from using loops to process data, no good solution to the memory exhaustion problem is available today.

Sometimes people make the mistake of assuming that client-side filters are faster because server-side filters provide the data in one motion after the server processes all the data. You therefore wait for a while without seeing anything and then see all the filtered records at one time. By comparison, client-side filters fetch and filter data continuously, so you see output as the command finds each matching record. However, the important indicator of performance is how long each type of filter takes to complete, and server-side filters are always faster.

The commands you are most likely to use with server-side filters are as follows:

  • Get-User. Retrieve basic Active Directory properties for any user account, including mail-enabled accounts.

  • Get-Mailbox. Retrieve Exchange-specific properties for mailboxes.

  • Get-DistributionGroup. Retrieve Exchange-specific properties for mail-enabled groups.

Each of the commands you can use to work with user accounts, groups, and mailboxes supports a different set of filterable properties. To discover which properties are available for filtering, you can use PowerShell to query the properties of a returned object. For example:

Get-Mailbox -Identity Redmond | Get-Member | Where-Object {$_.MemberType –eq 'Property'} | 
Sort-Object Name | Format-Table Name

This set of commands calls a command to return some information about an object. It then pipes the information returned by the first command to the Get-Member cmdlet, which extracts information about the properties. You sort the properties by name and output them in table format. Here’s an excerpt from the output:

Name
----
AcceptMessagesOnlyFrom
AcceptMessagesOnlyFromDLMembers
AddressListMembership
Alias
AntispamBypassEnabled
CustomAttribute1
CustomAttribute10

WindowsEmailAddress

This method works for the Get-Mailbox, Get-CASMailbox, Get-User, Get-Recipient, Get-DistributionGroup, and Get-DynamicDistributionGroup cmdlets. You can use any of the values reported in a –Filter statement. For instance, the call you just made to Get-Mailbox reports that the custom attributes are available, so to find all mailboxes that have a value in the CustomAttribute10 property, you can generate a command like this:

Get-Mailbox –Filter {CustomAttribute10 –ne $Null}

If you look at the filterable properties reported by the Get-DynamicDistributionGroup cmdlet, you can see that the ManagedBy property is available for this dynamic distribution group, whereas it is not for mailboxes. Hence, you can execute a filter like this:

Get-DynamicDistributionGroup –Filter {ManagedBy –ne $Null}

When you create a filter, it is best to be as specific as possible. You can state several conditions within a filter. An example of a server-side filter that returns all the mailboxes in the Dublin office where the user name contains “Tony” is shown next. The Get-User cmdlet also works with this filter, but Get-Mailbox executes a tad faster because the server does not have to process accounts that are not mail-enabled.

Get-Mailbox –Filter {Office –eq 'Dublin' –and Name –like '*Tony*'}

After you have mastered server-side filtering, you will use it all the time to work with sets of users. For example, assume that you want to give a new mailbox quota to members of a certain department but no one else.

Get-User –Filter {Department –Eq 'Advanced Technology'} | Set-Mailbox
–UseDatabaseQuotaDefaults:$False
–IssueWarningQuota 5000MB –ProhibitSendQuota 5050MB –ProhibitSendReceiveQuota 5075MB

Inside Out WhatIf and Confirm

Before you execute any command to perform a bulk update of objects, you can run the command with the /whatIf switch added to force EMS to show you which objects will be altered. After you are sure that the correct set of objects will be updated, you can run the command without /whatIf, and EMS will perform the changes. The /confirm switch is also useful in terms of stopping administrators before they do something they should not. If you include the Confirm parameter, EMS prompts the administrator with “Are you sure that you want to perform this action” and waits for a “Y” or “Yes” response (or “A” for “all” if multiple objects are involved) before continuing. Act in haste, repent in leisure.

9. Transcripts

If you encounter a problem executing some EMS commands and need to produce some debug information to give to your support team or Microsoft, you can do this by generating a transcript. A transcript captures details of all commands executed in a session and is useful in terms of capturing the steps necessary to solve a problem or documenting steps to expose an issue that you want to report to Microsoft. You can combine this by adding the –Verbose parameter to most commands to gather a lot of information about what you’ve tried to do and what happened when you tried it. Use the Start-Transcript cmdlet to force EMS to capture debug information. For example:

Start-Transcript c:\Temp\Transcript.txt

All commands and output will be captured until you stop the transcript by using the Stop-Transcript cmdlet. At this point, you can examine the output with any text editor, and you’ll see something like the output shown in the following example.

**********************
Windows PowerShell Transcript Start
Start time: 20130313093116
Username : CONTOSO\Administrator
Machine : ExServer1 (Microsoft Windows NT 6.2.9200.0)
**********************
PS C:\temp> $env:path
C:\Windows\system32\WindowsPowerShell\v1.0\;C:\Windows\system32;C:\Windows;C:
\Windows\System32\
Wbem;C:\Windows\System32
\WindowsPowerShell\v1.0\;C:\Windows\idmu\common;C:\Program Files\System Center
Operations Manager 2007\;C:\Program Files\Microsoft\Exchange Server\V14
\bin;c:\temp
 
Others
 
- Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 4) - Identities, Piping
- Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 3) - Using common and user-defined variables, Using PowerShell ISE with Exchange
- Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 2) - Handling information EMS returns , Selective output
- Exchange Server 2013 : The Exchange Management Shell - EMS basics (part 1) - Command editing
- Exchange Server 2013 : The Exchange Management Shell - Using remote Windows PowerShell - Connecting to remote PowerShell
- Exchange Server 2013 : The Exchange Management Shell - How Exchange uses Windows PowerShell
- Active Directory Planning and Installation : Installing Active Directory - Promoting a Domain Controller
- Active Directory Planning and Installation : Understanding Domain and Forest Functionality
- Active Directory Planning and Installation : Verifying Network Connectivity - Tools and Techniques for Testing Network Configuration
- Active Directory Planning and Installation : Verifying the Filesystem - Setting Up the NTFS Partition
 
 
Top 10
 
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
Facebook
 
Technology FAQ
- IIS Web site works in all browsers except Safari on Mac
- notification
- alternative current in to a pc
- parse url in JavaScript
- Dual WAN on a Fortigate 60
- Should Sys Admins (Domain Admins) also have user accounts?
- DR solution for data warehouse
- C# Creating Plugins
- SCCM 2007 collection by OU not showing all pc's
- Email account got spoofed?
programming4us programming4us