Getting an overview of all ActiveSync devices in the Exchange-organization

In Exchange 2007, we can get use the Get-ActiveSyncDeviceStatistics to retrieve statistics for a specific ActiveSync-device. We must supply either a device identity or a mailbox name. In Exchange 2010, the same cmdlet exists, but we also got a new useful cmdlet; Get-ActiveSyncDevice. This cmdlet lists all devices in the organization that have active Microsoft Exchange ActiveSync partnerships.

To provide a way to list all ActiveSync devices in the Exchange organization that works against both Exchange 2007 and Exchange 2010, Ive created a script named Get-ActiveSyncDeviceInfo.ps1. The script outputs each device as an object, making it easy to work with the results. You might i.e. export all devices to a CSV-file by piping the results to Export-Csv.

You might also create graphs based on the results, like I demonstrated in a previous blog-post.

Im aware that the script could be more effective, using Get-CASMailbox and a server-side filter to sort out only mailboxes that got the property HasActiveSyncDevicePartnership set to “true”. However, Ive experienced that this property isnt reliable. Several mailboxes that does have the HasActiveSyncDevicePartnership set to true doesn`t have an ActiveSync devices associated. You might want to use this approach anyway in larger organizations, although I chose to skip it and rather loop through all mailboxes.

Creating graphs with Windows PowerShell

Joel Bennett (PowerShell MVP) has created a script module named PowerBoots, which makes it easier to create graphical user interfaces in PowerShell v2 (available as a snapin for PowerShell v1).

Project description for the PowerShell PowerBoots project on CodePlex:

PowerBoots makes it easier for scripters to create graphical user interfaces in PowerShell, exposing much of the power of WPF to PowerShell in a simple syntax which supports events, threading, and much, much, more.

PowerBoots is written as a script module which dynamically generates functions into static script files for each WPF control, combined with a compiled module called PoshWpf which was originally part of PoshConsole (and includes the Out-Wpf cmdlet and New-BootsWindow cmdlets among others) … the module enables threaded UIs as well as enabling support for styles, control templates and data templates.

Included in the PowerBoots script module are also the VisiFire Charts Package, a set of data visualization controls powered by Microsoft Silverlight and WPF.
This makes it possible to create graphs with Windows PowerShell, which Ill provide some examples on.
Before we move on to the examples, I would encourage you to go look at the PowerBoots site as well as the blog posts on PowerBoots on Joel
s  blog.

Creating graphs for Active Directory user accounts

The first example will get all users in the East Organizational Unit from a lab-domain:

image

It will then show the number of users per OU in a chart:

image

image

image

As you can see in the last graph, there are some animations available when you hover the mouse over a bar, it displays the number of users.
Its also possible to export the graphs to images, using Export-BootsImage. If you want to do that, remember to turn off animations by setting AnimationsEnabled equal to false, else the exported images wont display any graphs.

PowerShell code to generate a chart to show Active Directory users per OU:

#Import Active Directory-module
Import-Module ActiveDirectory

#Import PowerBoots-module
Import-Module PowerBoots

#Create graph
New-BootsWindow -Content {
Chart -Width 400 -Height 200 -Theme Theme3 (
DataSeries $(
$OUs = Get-ADOrganizationalUnit -SearchBase “OU=East,DC=contoso,DC=no” -SearchScope OneLevel -Filter * |
Select-Object Name,DistinguishedName
foreach ($OU in $OUs) {
$count = (Get-ADUser -Filter * -SearchBase $OU.DistinguishedName | Measure-Object).Count
DataPoint -YValue ($count) -AxisXLabel $OU.Name
}
) -RenderAs bar
)} -Title "Number of users per OU"

Note that you can control the look by customizing i.e. the “Theme” and “RenderAs” parameters.
Valid “RenderAs” parameters: Column, Line, Pie, Bar, Area, Doughnut, StackedColumn, StackedColumn100, StackedBar, StackedBar100, StackedArea, StackedArea100, Bubble, Point.

For a list of samples, I would encourage you to visit the VisiFire Charts Gallery.

Creating graphs for Microsoft Exchange mailboxes

This example will show the number of Exchange mailboxes per database:

image

image

image

PowerShell code to generate a chart to show Exchange mailboxes per database:

Creating graphs for Microsoft Exchange ActiveSync devices


The last example will show Exchange ActiveSync devices per type:

image

image

image

PowerShell code to generate a chart to show Exchange ActiveSync devices by type:

Note that this example will work against Exchange Server 2010. For working against Exchange 2007 you will need to take a different approach using Get-ActiveSyncDeviceStatistics, since the Get-ActiveSyncDevice cmdlet doesnt exist.

We ve looked at some examples of practical usage of the chart features available in PowerBoots and VisiFire, and as you can imagine, you may create graphs for whatever you would like to.
An example of practical usage in addition to the above examples would be to schedule a script which exports the charts to images using Export-BootsImage, and then copies the images to i.e. a webserver, which displays the images on the IT-department
s intranet.

Managing calendar permissions in Exchange Server 2010

In legacy versions of Exchange Server we could use PFDAVAdmin to manage calendar permissions, or alternatively the 3rd party tool SetPerm.
With Exchange Server 2010 calendar permissions can be managed using the *-MailboxFolderPermission cmdlets. While these cmdlets can be used to manage permissions on any mailbox folder, well focus on calendar permissions.

In fact we got 4 *-MailboxFolderPermission cmdlets in Exchange Server 2010:

Since Ill be focusing on managing default permissions , which is an existing ACL on the calendar folder, we need to use the Set-MailboxFolderPermission cmdlet:

image

To grant “Reviewer”-permissions for the “Default” user, we would run the following:

image

Some companies have a policy that everyone must share their calendars with all users. Since its now possible to manage calendar permissions using PowerShell, Ive written a script to accomplish this task; Set-CalendarPermissions.ps1.

While this script could be scheduled to run on a regular basis, a better approach for managing calendar permissions for new mailboxes are the use of the Scripting Agent which is a part of the Cmdlet Extension Agents, a very useful feature introduced in Exchange Server 2010.

Pat Richards has posted an excellent post on how to automatically modify new mailboxes using the Scripting Agent.

Starting an RemoteApp through RD Web Access and RD Gateway fails with “The logon attempt failed”

In Windows Server 2008 R2, it`s possible to use RD Web Access and RD Gateway for starting RemoteApp applications, using Single Sign-On (SSO).
The Remote Desktop Services Team has a great article here on how to configure this setup.

While troubleshooting a problem with the SSO-feature lately, we got an error message saying “The logon attempt failed”.

The solution turned out to be rather simple. While the default logon page for RD Web Access indicates “Domain/user name” for the user name field, using only the user name works fine:

image

 

This works fine as long as your not using RD Gateway and SSO, then the error message mentioned will occur when trying to start a RemoteApp.
When RD Gateway and SSO are being used, you must supply the domain as part of the user name (domain user name), else the SSO-feature will break.

I actually contacted Microsoft to clarify if it is possible to hardcode the domain name some way, and got the following answer:

I have taken time to discuss with our develop team. Please understand that there is no easy way to finish the task, because in RemoteApp mode RDP client ignores user name and domain name. We need to put a domain hint on the RD Web page. It is related to coding and design. If you want to request a feature or code change, you also can contact our Advisory Service by using the contact info published at <http://support.microsoft.com/gp/advisoryservice>.

Hopefully this will be possible in future Service Packs or OS releases.