Delivery Reports were introduced in Exchange 2010 and provide a method for users to verify that the messages they’ve sent have been successfully delivered. Users are able to generate these reports from the Delivery Reports screen in the Exchange Control Panel (ECP), which is also where Outlook 2010 will send them when they track a message. Since the ECP is driven by Exchange Management Shell cmdlets, we can create and view these reports using PowerShell. This gives you another tool to verify message delivery—in addition to the existing message tracking search functionality—but it can also provide the "read status" of a message. Let's start off with a basic example.

To create a delivery report from the shell, you first need to use the Search-MessageTrackingReport cmdlet. This will give you a list of one or more reports, and you'll need to pass the report id returned by this command to another cmdlet to get more details. Because of that, the bast way to handle this is to save the output in a variable:

$msg = Search-MessageTrackingReport -Identity allen -Recipients rob@uss.local -BypassDelegateChecking

If you want to search delivery reports for a mailbox other than your own, you need to use the -BypassDelegateChecking switch parameter as well. The search criteria can be based on the recipients of the message, as shown in the previous example, or on the subject of the message using the -Subject parameter.

After the search has completely successfully, use the Get-MessageTrackingReport cmdlet to review the results. To do this, we can simply iterate over each report id stored in the variable created in the previous step:

$msg | %{ Get-MessageTrackingReport -Identity $_.MessageTrackingReportId -BypassDelegateChecking }

For each message returned, the results should look similar to the following:

You can see that several details about the message are returned, including the delivery status, which was successful.

When tracking the status of a message sent to an external recipient, the we can only track the message as it leaves the last transport server on its way out of the organization. As long as this is successful, the TransferredCount will be incremented and the RecipientTrackingEvents will indicate that the message was transferred to a foreign organization.

Determining "Read Status" without Read Receipts

In addition to tracking the successful delivery of messages within the organization, you can also enable read tracking to determine the read status of a message. To do this, you first need to enable read tracking:

Set-OrganizationConfig -ReadTrackingEnabled $true

After this command has been run, read tracking will be enabled on all hub transport servers organization wide. By default, read status tracking for mailboxes is enabled. If read tracking needs to be disabled for specific users, you can disable on a per user basis using the Set-Mailbox cmdlet. For example:

Set-Mailbox -Identity steve -MessageTrackingReadStatusEnabled $false

At this point, read tracking has been enabled at the organization level, and we can determine the read status of a message by checking the delivery report. To do this, we’ll create another search. This time we’ll specify the subject of the e-mail for the search criteria:

$msg = Search-MessageTrackingReport -Identity allen -Subject 'Testing 1,2,3' -BypassDelegateChecking

According to the cmdlet help for the Get-MessageTrackingReport cmdlet, we should be able to determine the read status of a message by setting the -Status parameter to Read. So far, I haven't been able to get that to work (I'm looking into this). However, we can still track the read status for messages using the RecipientPath report template when running the Get-MessageTrackingReport cmdlet:

$msg | %{ Get-MessageTrackingReport -Identity $_.MessageTrackingReportId -BypassDelegateChecking -RecipientPathFilter rob@uss.local -ReportTemplate RecipientPath }

When using the RecipientPath report template, you also need to set the -RecipientPathFilter parameter to the recipient address for the message. The above command produces the following output:

Notice that the RecipentTrackingEvents property shows that the message was submitted, delivered, and is also set to Read.

If you don't have organization read tracking enabled, you can still check the read status of a message from PowerShell with the EWS Managed API. There is a great code sample for this posted here by a user in the Exchange 2010 forums on TechNet.

One of the more common Lync 2010 client questions is: How do I enable "Appear Offline" status? For on-premises deployments, this can easily be controlled using the Lync Management Shell. There is an EnableAppearOffline setting that is controlled by in-band provisioning, which means configuration data is defined via a server-side policy, and downloaded by clients after sign-in. You can enable appear offline status for all of your clients by modifying each of your client policies with a simple Lync Management Shell one-liner:

Get-CSClientPolicy | Set-CSClientPolicy -EnableAppearOffline $true

Simple enough. Just restart the Lync client and you're all set.

What about Lync Online Clients?

If you're using Lync Online, this is a little more involved. Since there is no remote PowerShell interface for Lync Online, you can't change the client policies. You're only option is to fall back to modifying the registry on your client computers. Here is the reg add command you could use to script this:

Reg Add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Communicator" /V "EnableAppearOffline" /D 1 /T REG_DWORD /F

As you can see, this will create the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Communicator key, and then add a 32bit DWORD value under this key called EnableAppearOffline with a value of 1. You could always add this to a custom ADM template and apply the setting via group policy, if that makes things easier.

In either case, once the EnableAppearOffline setting has been enabled—after signing out and back into the Lync client—users will have the ability to select this option when setting their status, as shown above.

This is question I've been asked several times lately: How do I get the Exchange and Lync cmdlets loaded into the same shell? Well, with PowerShell v3 coming soon, this might not be an issue in the next wave of products thanks to the new auto loading modules feature. We'll see what happens. For now, there are a couple of options, but in both cases you'll probably want to setup a profile so it happens automatically when you start the shell. In this post I'll show you how to go about loading the cmdlets from a profile when the management tools are installed, and also how to use PowerShell remoting to load the cmdlets on workstations or servers that do not have the tools installed locally.

Management tools installed locally

If you have both the Exchange 2010 Management tools, as well as the Lync Server 2010 Management Tools installed on your workstation, add the following code to your PowerShell profile. If you don't have a profile setup, run Get-Help about_Profiles to learn how to create one. It's basically like a logon script for your PowerShell session. Here's the code you'd add to the profile:

#Load the Exchange cmdlets
. 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'
Connect-ExchangeServer -auto

#Import the Lync module
Import-Module Lync

As you can see here, were importing (also known as dotting or dot-sourcing) the RemoteExchange.ps1 script that is installed along with the Exchange tools. This will import the Exchange 2010 cmdlets and load some Exchange specific functions into the shell—one of which is the Connect-ExchangeServer function that will automatically connect to an Exchange server in the local AD site. After that, the Lync module is imported with a simple one-liner.

Remoting (management tools not installed)

If you don't have the Exchange 2010 Manangement tools, or the Lync 2010 Management Tools installed on your workstation, you can still manage both products from the command line using PowerShell remoting. Use the following syntax when setting up your PowerShell profile, but remember to update the server names to match your own environment:

#Load the Exchange cmdlets
$exch = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://exchange1/powershell
Import-PSSession $exch

#Import the Lync module
$lyncOptions = New-PSSessionOption -SkipRevocationCheck -SkipCACheck -SkipCNCheck
$lync = New-PSSession -ConnectionUri https://lync1/ocspowershell `
-SessionOption $lyncOptions `
-Authentication NegotiateWithImplicitCredential

Import-PSSession $lync

This code will import both the Exchange 2010 and Lync Server 2010 cmdlets into your shell session using implicit remoting. This code assumes you're using a domain account that has been assigned permissions in both Exchange and Lync, and your logged on Windows credentials will be used for authentication.

Also, notice that when importing the cmdlets from a Lync server, you need to specify an https end-point for the connection uri. This is because the OCSPowerShell virtual directory in IIS requires SSL. By default, this is secured with a self-signed certificate, so we've used a custom session options object to ignore SSL certificate validation.

Making use of the Pipeline

Now that you've got the cmdlets for both products loaded into a single session, you can work more efficiently. For example, you can kill two birds with one stone when it comes to mailbox-enabling and lync-enabling a user:

Enable-Mailbox -Identity Bob |
  Select-Object -Expand Identity |
    Enable-CsUser -SipAddressType EmailAddress -RegistrarPool pool.uclabs.ms

The Enable-Mailbox cmdlet creates a mailbox for an existing Active Directory user, but also outputs the Identity of the user upon completion. This object can be sent down the pipeline to Enable-CsUser, which happens to accept input via the pipeline for the Identity parameter. So with a quick one-liner, you can setup a user with a mailbox and lync-enabled account. Piping New-Mailbox to Enable-Csuser would also work using the above syntax.

If you work in an campus type of environment, where you have conference rooms spread out across multiple buildings or physical sites, you may have heard of the Room Finder functionality introduced with Exchange 2010 and Outlook 2010. The Room Finder allows users to easily locate a room resource when scheduling a meeting in Outlook. Instead of users having to scroll through the Global Address List (GAL) or try to guess which room resources are located in a particular location, they can select the appropriate room list, and see all of the available rooms. Take a look at this screen shot to see this in action:

Room lists are essentially just a special type of Distribution Group in Exchange. To populate the room list, you simply add one or more resource mailboxes to the group. After you've defined several room lists, you'll probably get to the point where you need to generate a report listing all of the room lists and their associated resource mailboxes. The key to generating a report is to simply query the members of each distribution group that are designated as a room list. Take a look at the following code:

foreach($roomlist in Get-DistributionGroup -RecipientTypeDetails RoomList) {
  $roomlistname = $roomlist.DisplayName
  Get-DistributionGroupMember $roomlist.alias |
    Select-Object @{n="Room List";e={$roomlistname}},
                  @{n="Room";e={$_.DisplayName}}
}

In a perfect world this code would be more elegant and make better use of the pipeline, but the foreach loop is used here as a workaround. Notice that as we iterate over each group, where retrieving the list of members using the Get-DistributionGroupMember cmdlet. When then pipe the output to Select-Object, where we use calculated properties to build a custom object:

This is good for reviewing the room lists members interactively, but in most cases you'll need to output this to an external file. We can do this by making a simple adjustment to our previous example. Simply save the output to a variable, and use that as your InputObject with Export-CSV, Out-File, etc.

$rooms = foreach($roomlist in Get-DistributionGroup -RecipientTypeDetails RoomList) {
  $roomlistname = $roomlist.DisplayName
  Get-DistributionGroupMember $roomlist.alias |
    Select-Object @{n="Room List";e={$roomlistname}},
                  @{n="Room";e={$_.DisplayName}}
}

Export-Csv -InputObject $rooms -Path C:\rooms.csv -NoTypeInformation

After running the above code, you could open up the rooms.csv file in Excel and use the Filter feature to easily view the rooms associated with each list. For more details on the Room Finder, check out this post on the Exchange Team blog.

You might work in an environment where all web traffic must go through an outbound web proxy. Of course, this can add some complexity when it comes to writing EWS scripts that target an external Exchange organization, such as a partner or a hosted platform like Exchange Online available through Office 365. Luckily, EWS supports the use of a web proxy, and this can be set via the ExchangeService object. Let's take a look at a couple of examples.

First, create an instance of the System.Net.WebProxy class, and set the URI for the proxy:

$proxy = new-object System.Net.WebProxy('http://tmg:8080')

Next, you can set the required user name and password on the $proxy object using the Credentials property, or you can use your logged on Windows credentials by setting the UseDefaultCredentials property to $true:

$proxy.UseDefaultCredentials = $true

Finally, assign your proxy object to the WebProxy property of your ExchangeService object:

$service.WebProxy = $proxy

Here's some code that uses the EWS Managed API 1.1 to send an e-mail message from an Exchange Online mailbox, with all of the web service operations going through an outbound proxy server:

Add-Type -Path 'C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll'
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService -ArgumentList Exchange2010_SP1
$service.Credentials = New-Object Microsoft.Exchange.WebServices.Data.WebCredentials -ArgumentList  'user@yourdomain.onmicrosoft.com', 'P@ssw0rd'

$proxy = new-object System.Net.WebProxy('http://tmg:8080')
$proxy.UseDefaultCredentials = $true
$service.WebProxy = $proxy

$service.AutodiscoverUrl('user@yourdomain.onmicrosoft.com', {$true})

$message = New-Object Microsoft.Exchange.WebServices.Data.EmailMessage -ArgumentList $service
$message.Subject = 'Test is a test'
$message.Body = 'This message is being sent through EWS with PowerShell'
$message.ToRecipients.Add('sysadmin@contoso.com')
$message.SendAndSaveCopy()

This post was a response to a query from one of my readers — thanks for the question, Nick. As a side note, the above code sample is based on a snippet from my guest post on the Hey Scripting Guy blog from a while back. For more details, you can check it out here.

I recently had the opportunity to give a presentation on the Idera PowerShell Power Hour Webcast. The topic was Exchange Enterprise Management with PowerShell, and I was excited to be able to answer so many great questions during the Q and A portion of the webcast. One request for help required a more lengthy explanation that I couldn't provide via web chat, and that's the reason for this post. If you've ever wanted to add one or more proxy address to a list of mailboxes from a CSV file, the solution provided here is for you.

First let me say that adding proxy addresses to multiple recipients can be done even easier with E-Mail Address Policies. You can read all about them here. However, if you are determined to get this done using PowerShell, it's actually pretty simple to do. I am going to assume you are at least running Exchange 2010 SP1, and that will allow us to utilize this cool hash table trick that can be used to add and remove values from multivalued properties.

Let's say that you have a CSV file setup like the following:

The Name column shown above contains aliases for existing mailbox-enabled users. The ProxyAddresses column contains a semi-colon separated list of addresses that need to be added to each associated mailbox. The key to making this work is converting the ProxyAddresses value into a collection of addresses. We can use the Import-CSV cmdlet to read our source file, and for each record, we'll process the list of ProxyAddresses by adding them to each corresponding mailbox. Let's start first with a simple example:

PS C:\> Import-Csv C:\AddressList.csv | ForEach-Object{$_.ProxyAddresses -split ';'}
ds@domain1.com
dave@domain2.com
sd@domain1.com
steve@domain2.com

Notice that as we loop through each record, we take the value assigned to the ProxyAddresses column and split it into an array using the PowerShell v2 split operator. When we split this value, we can simply iterate over each item returned and the add proxy addresses to the mailbox. Here's our final code sample that will get this job done:

Import-Csv C:\AddressList.csv | ForEach-Object{
  $name = $_.Name
  $proxy = $_.ProxyAddresses -split ';'
  Set-Mailbox -Identity $name -EmailAddresses @{add= $proxy}
}

The -EmailAddresses parameter is available for cmdlets that modify other recipient types. If needed, replace the call to Set-Mailbox with Set-MailUser, Set-MailContact, etc. and use the same kind of syntax to add proxy addresses.

This post is inspired by a question asked during my presentation at the last Arizona PowerShell User Group (AZPOSH) meeting. After I demonstrated Exchange management via PowerShell implicit remoting, one of our members said, "Ok, so how do I do that over the internet?". Due to time constraints, I didn't go into it the process in great detail, so I've decided to do that here, in this post. To demonstrate this configuration, I'll use a basic topology with a single Exchange 2010 server running the core roles (hub, cas, mailbox). I will be publishing the PowerShell virtual directory to the internet via HTTPS using Forefront Threat Management Gateway (TMG), as shown in the diagram below.

Implementing a TMG server is not a requirement to make this work. But, when it comes to exposing Exchange servers to the Internet, its considered a best practice to publish them using a reverse proxy solution, such as TMG or UAG. However, you could accomplish this using a simple NAT translation on your firewall, directing traffic from the internet directly to your Exchange server on the internal network. If someone wanted to roll the dice and go with that type of configuration, they could skip the upcoming section on TMG, but it increases the attack surface and is considered bad practice.

Configuration Steps on the Exchange Server

The only thing that needs to be done on the Exchange server is a modification to the PowerShell virtual directory in IIS. In the Exchange Management Shell, use the following one-liner to enable Basic Authentication for the PowerShell virtual directory:

Get-PowerShellVirtualDirectory | Set-PowerShellVirtualDirectory -BasicAuthentication $true

Specifying the identity of the virtual directory is easier done via the pipeline, as shown above. However, this command would modify the virtual directory on every Exchange server in the organization, if you had more than one. If you want to specify a particular server, use the -Server parameter with the Get cmdlet, and pipe that over to the Set cmdlet.

TMG Configuration

I don't want to reinvent the wheel here, so I'm just gonna focus the bare minimum. I'm assuming that if you have TMG and Exchange, you probably already have at least OWA published . If you need step-by-step guidance on installing certificates, and publishing Exchange services, such as OWA and Outlook Anywhere, then you should read Greg Taylor's whitepaper titled Publishing Exchange Server 2010 with Forefront UAG and TMG.

The upcoming TMG configuration steps are based on the following assumptions.

• Certificates — You already have a 3rd party commercial certificate installed on the TMG server, it includes SANs for OWA, Outlook Anywhere, and maybe even Autodiscover. For example, mail.interfacettlabs.com, oa.interfacettlabs.com, autodiscover.interfacettlabs.com, etc.
• Listener — The TMG server is running in workgroup mode, you're using secure LDAP to pre-authenticate users against Active Directory, and your commercial certificate is associated with the listener.
• Publishing Rule — You have publishing rules for OWA, Outlook Anywhere, and maybe even for ActiveSync. We won't touch these, we'll create a new publishing rule for PowerShell.

There are several ways to deploy TMG, so in reality, your deployment does not need to match the above configuration. For example, you're not required to use pre-authentication, although it's practically pointless not to. Again, check out the whitepaper for more details if you need to deploy TMG from scratch. With all of that in mind, let's get started.

1. From within the TMG console, right click on Firewall Policy, go to New, and select Web Site Publishing Rule:

   

2. On the New Web Publishing Rule Wizard, enter a name for your rule, such as Exchange PowerShell:

   

3. For the Rule Action, select Allow, otherwise we won't be able to connect. Click Next:

   

4. In our lab topology, we only had one server, so we'll select Publish a Single Website or Load Balancer and click Next:

   

5. Stick with the default Server Connection Security setting and use SSL to connect to the published web site, which in this case is hosted on the Exchange 2010 server. This will ensure that remote PowerShell connections use bridged SSL; meaning encrypted from the internet to TMG, and then from TMG to Exchange. Click on Next:

   

6. On the Internal Publishing Details screen, enter the FQDN the TMG server should use to connect to the Exchange server and click on Next:

   

7. Next, you'll need to enter /powershell/* for the path to be published on the Exchange server. Click Next:

   

8. Now you'll need to enter your externally accessible FQDN in the public name field. Again, the path should be /powershell/* and click on Next:

   

9. As discussed previously, we'll use a listener that was configured for one of the other Exchange publishing rules. Click Next:

   

10. This next step is important. On the Authentication Delegation screen, select Basic Authentication. This needs to match the authentication settings for the virtual directory, which was already configured in the previous section. Click Next:

    

11. On the User Sets screen, keep the default setting of All Authenticated Users. Click Next:

    

12. Finally, the PowerShell IIS application on the Exchange server has been published. Click on Finish:

    

Testing it out

Go to any machine external to your environment that has an internet connection. This can be any machine with PowerShell v2, it doesn't need to be in the same domain as the Exchange server. Start PowerShell and use the following syntax to create a new session:

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://mail.interfacettlabs.com/powershell -Authentication basic -Credential (Get-Credential)

This command will prompt you for your domain credentials, then establish a PSSession with the Exchange server published through TMG. Notice that we've specified Basic authentication, and used the public name as the FQDN in the connection uri. After the session is created, the next step is to import it:

Import-PSSession $session

As you can see, it works perfectly. You should now have a publicly accessible endpoint for managing your on-premise Exchange environment through PowerShell remoting. As it turns out, the implicit remoting configuration is identical for Office 365, see this post for more details on that.

One Last Note on Testing in Lab Environments

If you are doing this in a lab, you might be dealing with self-signed certificates, or certificates issued from an internal CA. Depending on the client you are testing from, the certificates may not be trusted, and PowerShell may not be able to validate the certificates, depending on a number of factors. To get around this and basically ignore all certificate issues all together, you can create a PSSessionOption object that disables these certificate validation checks:

$so = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck

Then make sure you assign that PSSessionOption object to the -SessionOption parameter of New-PSSession:

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://mail.interfacettlabs.com/powershell -Authentication basic -Credential (Get-Credential) -SessionOption $so

And finally, import the session:

Import-PSSession $session

That concludes this post, I hope you find it useful, or at least interesting. For more on managing Exchange via remoting, check out my previous posts on the subject, all of which can be found here.

Tuesday night I downloaded and installed the Windows 8 Developer Preview and got a chance to test drive PowerShell v3. Pretty impressive so far — you should go download it and check it out. Tonight I decided to download the new Windows Server 8 preview to compare the differences between the client and server operating systems. One of the things that confused me about 2008 R2 was that there were PowerShell modules for things like Windows Failover Clustering and Network Load Balancing, and not for major core services. For example, there were no cmdlets for basic server administration tasks like managing DNS, DHCP, or File and Print services. Well, the good news is that will change with Windows Server 8.

DNS

Want to add a host (A) record to a DNS zone on a 2008 R2 box using the shell? Sounds seemingly simple, yet it is actually not an easy thing to do. In the Windows Server 8 preview there is a DnsServer module, and as you would expect, you can accomplish this with just a couple of commands. Once the DNS server role is installed, import the module:

Import-Module DnsServer

Then its just a matter of running the Add-DnsServerResourceRecordA cmdlet:

Add-DnsServerResourceRecordA -Name mail2 -IPv4Address 192.168.0.10 -ZoneName powershell.local

Of course, there are plenty of other cmdlets in this module that allow you to add, modify, and remove other types of DNS records, as well as modify zone settings, and more.

DHCP

There are over a hundred cmdlets in the DhcpServer module. From reviewing the output ofGet-Command -Module DhcpServer, it looks like just about anything that can be done with Dhcp can be scripted through PowerShell v3. One of the most obvious examples would be creating a scope. Just import the module after the role is installed:

Import-Module DhcpServer

And run the Add-DhcpServerv4Scope cmdlet:

Here's the output from Get-DhcpServerv4Scope after I created my scope:

PS C:\> Get-DhcpServerv4Scope | fl

ScopeId          : 192.168.0.0
Name             : LAN
Description      :
SuperscopeName   :
SubnetMask       : 255.255.255.0
StartRange       : 192.168.0.20
EndRange         : 192.168.0.50
LeaseDuration(s) : 4.00:00:00
NapProfile       :
NapEnable        : False
Delay(ms)        : 0
State            : Active
Type             : Dhcp
MaxBootpClients  : 4294967295
ActivatePolicies : True

This is not only going to be great for automation, but also for reporting.

File and Print Services

For managing file and print services there are a couple of different modules. First, the FileServer module contains over 40 cmdlets that allow you to add, remove, and modify shares. You can also do other things, like killing all open files with a one-liner:

In addition, there is a module called PrintManagement. As usual, the cmdlet names are pretty self describing:

PS C:\> Get-Command -Module PrintManagement

CommandType     Name                    ModuleName
-----------     ----                    ----------
Function        Add-Printer             PrintManagement
Function        Add-PrinterDriver       PrintManagement
Function        Add-PrinterPort         PrintManagement
Function        Get-PrintConfig         PrintManagement
Function        Get-Printer             PrintManagement
Function        Get-PrinterDriver       PrintManagement
Function        Get-PrinterPort         PrintManagement
Function        Get-PrintJob            PrintManagement
Function        Remove-Printer          PrintManagement
Function        Remove-PrinterDriver    PrintManagement
Function        Remove-PrinterPort      PrintManagement
Function        Remove-PrintJob         PrintManagement
Function        Rename-Printer          PrintManagement
Function        Restart-PrintJob        PrintManagement
Function        Resume-PrintJob         PrintManagement
Function        Set-PrintConfig         PrintManagement
Function        Set-Printer             PrintManagement
Function        Suspend-PrintJob        PrintManagement

I could go on and on, but I think you get the idea. I'll be posting a lot more about PowerShell v3 and Server 8 in the future. If you have an MSDN subscription, head over to the MSDN Subscriber site now and download the bits.

Edit - 9/16/2011 3:20:05 PM: I was chatting with PowerShell MVP alexandair earlier today and realized that these modules don't need to be explicitly loaded. For example, if you run the Get-DhcpServerv4Scope cmdlet, PowerShell will automatically load the DhcpServer module for you.....awesome stuff!!!

This week, Microsoft is holding its BUILD conference, which shows developers whats coming in the next version of Windows. Yesterday, they released the Windows Developer Preview, which a pre-beta version of Windows 8 for developers. Now that PowerShell is part of the operating system, this also means we get a preview of PowerShell v3, and as you would probably guess, so far it is pretty impressive. The first thing I looked at was how many cmdlets were available using Get-Command. With PowerShell v2, there were 236 core cmdlets. In the Windows Developer Preview, you can see that over 100 core cmdlets have been added to the shell:

Next, I wanted to see how many modules were included with the OS. Windows 7 included 5 or 6 PowerShell modules. In the Windows Developer Preview, there are over 230. Some of the more interesting ones I've noticed so far are dedicated to managing DNS, network adapters and TCP/IP, iSCSI, Scheduled Tasks, and Scheduled Jobs.

The PowerShell ISE (Integrated Scripting Environment) has also gotten quite an upgrade. IntelliSense has been included in the script editor and input pane, in addition to a new command window that allows you to graphically compose commands by selecting a cmdlet name, and entering the parameter values into the fields beneath it.

Honestly, I wasn't surprised to see intellisense in the ISE for cmdlets. But, I was impressed when I noticed that intellisense also works for parameter arguments. For example, in the screen shot below, you can see that I've typed Get-Process -Name into the script editor, and I'm given a list of available process to select:

And finally...bracket highlighting. The lack of this basic feature really made it difficult for me to primarily use the ISE in v2, but with v3, it looks like that has been solved:

Keep in mind that this is a very early preview, so a lot of this could change drastically in time. You can download the Windows Developer Preview from MSDN. There are x86 and x64 versions, along with the Windows Developer Preview with developer tools, which includes Microsoft Visual Studio 11 Express, Expression Blend 5, and 28 Metro style apps including the BUILD Conference app.

Have you ever used that "Test E-mail AutoConfiguration" utility in Outlook? It's a useful tool that will query the autodiscover service, showing you exactly what CAS URLs are being handed to a particular user, and what the MAPI/HTTP endpoint is for their Exchange mailbox. You can run this tool by pressing the Ctrl button, right clicking on the Outlook 2007/2010 tray icon, and selecting "Test E-mail AutoConfiguration". This is nice, but there are times when I want to be able to determine this information for a user without having to fire up Outlook, or when Outlook isn't installed where ever I happen to be at the moment. My solution for this is a PowerShell function that will retrieve this information using the EWS Managed API. Here's the code:

function Test-Autodiscover {
    [CmdletBinding()]
    param(
      [Parameter(Position=1, Mandatory=$true)]
      [String]
      $EmailAddress,

      [ValidateSet("Internal", "External")]
      [Parameter(Position=2, Mandatory=$false)]
      [String]
      $Location = "External",      

      [Parameter(Position=3, Mandatory=$false)]
      [System.Management.Automation.PSCredential]
      $Credential,

      [Parameter(Position=4, Mandatory=$false)]
      [switch]
      $TraceEnabled,

      [Parameter(Position=5, Mandatory=$false)]
      [bool]
      $IgnoreSsl = $true,

      [Parameter(Position=6, Mandatory=$false)]
      [String]
      $Url
      )

      begin{
        Add-Type -Path 'C:\Program Files\Microsoft\Exchange\Web Services\1.1\Microsoft.Exchange.WebServices.dll'
      }

      process {
        $autod = New-Object Microsoft.Exchange.WebServices.Autodiscover.AutodiscoverService
        $autod.RedirectionUrlValidationCallback = {$true}
        $autod.TraceEnabled = $TraceEnabled

        if($IgnoreSsl) {
          [System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
        }

        if($Credential){
          $autod.Credentials = New-Object Microsoft.Exchange.WebServices.Data.WebCredentials -ArgumentList $Credential.UserName, $Credential.GetNetworkCredential().Password
        }

        if($Url) {
          $autod.Url = $Url
        }

        switch($Location) {
          "Internal" {
            $autod.EnableScpLookup = $true
            $response = $autod.GetUserSettings(
              $EmailAddress,
              [Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::InternalRpcClientServer,
              [Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::InternalEcpUrl,
              [Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::InternalEwsUrl,
              [Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::InternalOABUrl,
              [Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::InternalUMUrl,
              [Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::InternalWebClientUrls
            )

            New-Object PSObject -Property @{
              RpcClientServer = $response.Settings[[Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::InternalRpcClientServer]
              InternalOwaUrl = $response.Settings[[Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::InternalWebClientUrls].urls[0].url
              InternalEcpUrl = $response.Settings[[Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::InternalEcpUrl]
              InternalEwsUrl = $response.Settings[[Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::InternalEwsUrl]
              InternalOABUrl = $response.Settings[[Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::InternalOABUrl]
              InternalUMUrl = $response.Settings[[Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::InternalUMUrl]
            }
          }
          "External" {
            $autod.EnableScpLookup = $false
            $response = $autod.GetUserSettings(
              $EmailAddress,
              [Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::ExternalMailboxServer,
              [Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::ExternalEcpUrl,
              [Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::ExternalEwsUrl,
              [Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::ExternalOABUrl,
              [Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::ExternalUMUrl,
              [Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::ExternalWebClientUrls
            )

            New-Object PSObject -Property @{
              HttpServer = $response.Settings[[Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::ExternalMailboxServer]
              ExternalOwaUrl = $response.Settings[[Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::ExternalWebClientUrls].urls[0].url
              ExternalEcpUrl = $response.Settings[[Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::ExternalEcpUrl]
              ExternalEwsUrl = $response.Settings[[Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::ExternalEwsUrl]
              ExternalOABUrl = $response.Settings[[Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::ExternalOABUrl]
              ExternalUMUrl = $response.Settings[[Microsoft.Exchange.WebServices.Autodiscover.UserSettingName]::ExternalUMUrl]
            }
          }
        }
      }
<#
    .SYNOPSIS
        This function uses the EWS Managed API to test the Exchange Autodiscover service.

    .DESCRIPTION
        This function will retreive the Client Access Server URLs for a specified email address
        by querying the autodiscover service of the Exchange server.

    .PARAMETER  EmailAddress
        Specifies the email address for the mailbox that should be tested.

    .PARAMETER  Location
        Set to External by default, but can also be set to Internal. This parameter controls whether
        the internal or external URLs are returned.

    .PARAMETER  Credential
        Specifies a user account that has permission to perform this action. Type a user name, such as
        "User01" or "Domain01\User01", or enter a PSCredential object, such as one from the Get-Credential cmdlet.

    .PARAMETER  TraceEnabled
        Use this switch parameter to enable tracing. This is used for debugging the XML response from the server.    

    .PARAMETER  IgnoreSsl
        Set to $true by default. If you do not want to ignore SSL warnings or errors, set this parameter to $false.

    .PARAMETER  Url
        You can use this parameter to manually specifiy the autodiscover url.        

    .EXAMPLE
        PS C:\> Test-Autodiscover -EmailAddress administrator@uclabs.ms -Location internal

        This example shows how to retrieve the internal autodiscover settings for a user.

    .EXAMPLE
        PS C:\> Test-Autodiscover -EmailAddress administrator@uclabs.ms -Credential $cred

        This example shows how to retrieve the external autodiscover settings for a user. You can
        provide credentials if you do not want to use the Windows credentials of the user calling
        the function.

    .LINK
        http://msdn.microsoft.com/en-us/library/dd633699%28v=EXCHG.80%29.aspx

#>
}

There are a few ways to use this Test-Autodiscover function. First, lets say that you are logged on to a domain workstation. Running the function with the following parameters will use your logged on credentials to perform an SCP look up and return the internal settings for the specified e-mail address:

Test-Autodiscover -EmailAddress administrator@uclabs.ms -Location internal

You can omit the -Location parameter, which by default is set to "External", and the function will use DNS to locate autodiscover and retrieve the external settings:

Test-Autodiscover -EmailAddress administrator@uclabs.ms

Finally, you might be testing this from the a machine outside your domain. Just create a PSCredential object using the Get-Credential cmdlet and assign it to the -Credential parameter of the function. For example, here's the result from testing autodiscover for an Exchange Online mailbox hosted through Office 365:

Test-Autodiscover -EmailAddress admin@uclabs.onmicrosoft.com -Credential $cred

In order to use this function you'll need a few things. First, if you haven't already, go download the EWS Managed API. You'll also need the .NET Framework 3.5.1 and PowerShell v2 installed. At that point, all you need to do is add the Test-Autodiscover function to your shell session and you're good to go.