Delivery Class Throttling

Delivery Class Throttling is an automatic process that was introduced with Exchange 2010 SP1. It is designed to address the following issues that administrators may experience in a messaging environment:

  • Because more resources are required to send messages that have large attachments or that are sent to multiple recipients, other message delivery operations may experience increased latency.
  • A high rate of mailbox delivery operations may reduce the user interactive mailbox experience. For example, users may experience slow refresh or update times when they access their mailboxes.
  • No centralised method is available to control how a specific user may inadvertently affect the resources of a Transport server. Such an effect may occur if the user sends messages that have high delivery costs in terms of number of recipients or total message size or both.

Delivery Class Throttling works by assigning an internal cost to messages based on:

  • Message size
  • Number of recipients
  • Frequency of transmission

As the message is being processed by the Categorizer, messages with a higher cost will be assigned a lower priority and placed in separate MAPI delivery queues.  Messages in a higher prirority MAPI queue will be delivered at a higher rate than those in a lower priority queue (the documented ration is 20:1).

Currently there is no documented way to view or modify this behaviour.

Open File Dialog Box

Often when working with PowerShell you will want to specify a file to read data from it.  Whilst the file path can be hard-coded into your script, or passed as a parameter it is often more convenient to take advantage of windows functionality that people have become used to.

The code below allows you to call one of the standard windows libraries to open the dialog box used for choosing files.  The code comes from a technet article which explains what each line of code does should you be interested.  The article can be found at Use a .NET Framework Class to Open a File Dialog Box

 

[reflection.assembly]::loadwithpartialname("System.Windows.Forms") | Out-Null
$openFile = New-Object System.Windows.Forms.OpenFileDialog
$openFile.Filter = "txt files (*.txt)|*.txt|All files (*.*)|*.*" 
If($openFile.ShowDialog() -eq "OK") {get-content $openFile.FileName}

Using AutoDiscover in a Multi-forest Environment

In a simple, one Forest Exchange deployment, Autodiscover will work for internal users without needing to be configured. In many cases, for example we have multiple sites or multiple Client Access Servers, Autodiscover can be enhanced with a little configuration, but it will still work.

However, if you are running in an Environment that has multiple forests and using linked mailboxes, you will need to configure Autodiscover for those users who have linked mailboxes before it will work for them.

The issue is caused by the Service Connection Point (SCP), or rather the lack of SCPs. An SCP is a known location in Active Directory that services can use to locate information. As each Client Access Server is added to your organisation, it adds it’s information to the SCP. When Outlook clients start, they query their Active Directory forest SCP to retrieve a list of Client Access Servers than can be used for Autodiscover. In the case of linked-mailboxes the user’s forest contains no Exchange servers, therefore there are no SCPs to be found.

To remedy this, the SCPs from the forest containing the Exchange servers should be exported and then imported into the forest containing the linked-mailbox user accounts. This can be accomplished with the following command in the Exchange Management Shell:

Export-AutoDiscoverConfig

This cmdlet has one mandatory parameter -TargetForestDomainController and this should be the FQDN of a domain controller in the forest that the user accounts are contained in. Other parameters can be used to specify which Domain controller to copy the information from as well as credentials.

Creating you own GUI Application

PowerShell is a wonderful tool to gather information and analyse or display it. However, it can be somewhat daunting for the novice user to use. It is not unusual for tools and scripts to be written on behalf of less-technical staff, however basic scripts still require interaction from the command prompt.

One solution to this is to write a GUI front-end to your PowerShell code. Whilst PowerShell doesn’t have GUI commands provided natively as cmdlets, it is the scripting language for .NET so has access to all the .NET routines, including those needed to produce GUIs.

The process is simple enough, however a bit long-winded. The team at the Lync PowerShell blog have put together an easy to follow step-by-step guide of how to do this. This guide can be found here.

Changing Screen Colours

Changing screen colours can be easily done using the .NET [Console] object with commands similar to below:

[Console]::ForegroundColor = "yellow"
[Console]::BackgroundColor = "red"

After changing the background a Clear-Host  command should be issued.

To put the colours back to the default issue the following command:
[Console]::ResetColor()

Again, if you have previously changed the background colour and are reverting it you will need to run Clear-Host