If you're planning on deploying single sign-on with Office 365, you'll probably come to find that the AD FS forms based sign-in experience can be a little irritating for end-users. For example, let's say I've deployed AD FS, and I'm publishing that through an AD FS proxy. When a federated user hits the Microsoft Online Portal from the outside world, they enter their username, and the password field gets greyed out. Just underneath that, there is a link will send them over to the AD FS server on-premises (via the AD FS proxy) server to enter their AD credentials. So far, this is fine. It's the next step (clicking on the Sign in at Office365lab.us link) that becomes confusing.

Once redirected, they'll end up at an AD FS sign-in page, like the one below. This is where a couple of minor issues come into play. First, for the sake of consistency, it would probably be better to update the label and description for the user name field. The previous screen that they were on was asking for a "User ID" and now I'm asking them for a "user name". Even more important is the example provided just to the right of the user name field. I'd rather ask them to use their e-mail address, instead of their login in the format of domain\username. In many cases, they have no idea what the netbios name of their domain is.

1. Modify the label and description for the user name field

On the AD FS proxy server, navigate to C:\inetpub\adfs\ls\App_GlobalResources. You'll want to find the CommonResources file for each required language. In this example, I only need to modify the english version, so I'll open up the CommonResources.en.resx file in notepad.

Look for some xml code like this, which starts on line 180. This will be the description just to the right of the user name text box. Change the value to the desired text, such as an example of what an e-mail address should look like.

  <data name="UsernameExample" xml:space="preserve">
    <value>Example: joe@office365lab.us</value>
  </data>

On line 183, you can update the text box label. In this case, I'm going to tell them to use their User ID, which is the same as the portal sign in page:

  <data name="UsernameLabel" xml:space="preserve">
    <value>User ID: </value>
  </data>

Save the file and try logging in again. You should notice the the label and description are now updated:

2. Even better: auto-populate the User ID

Instead of asking for their e-mail address again, how about populating it for them? This trick comes from dkershaw_MSFT who posted a gem on the Office 365 community forum. This will allow you to modify the ASP.NET code so that the user name field is automatically populated. The ASP.NET code is not compiled, so even if you do not have Visual Studio installed, you can simply open the file in notepad and modify the code.

Open the FormsSignIn.aspx.cs file which is also located in C:\inetpub\adfs\ls folder. You'll need to add a couple using directives to the beginning of the file:

using System.Web;
using System.Collections.Specialized;

Then, inside the Page_Load() method, add the following C# code:

        string url = Context.Request.Url.AbsoluteUri;
        NameValueCollection parameters = HttpUtility.ParseQueryString(url);
        string userIdentity = parameters["username"];
        if (!String.IsNullOrEmpty(userIdentity))
        {
            UsernameTextBox.Text = userIdentity;
        }

After saving the file, go back to the portal sign in page. You should get redirected back to AD FS and the e-mail address field will be filled out and ready to go:

I made one small change to the code. I set focus on the password field since the e-mail address will already be populated on the form. When a user gets redirected, they simply type in the password and hit enter.

By default, AD FS servers use Windows Integrated Authentication (WIA), and only the AD FS proxy servers are setup for Forms Based Authentication (FBA). If you are not using an AD FS proxy, you are likely publishing your internal AD FS servers to the internet through something like TMG, and therefore external users are not seeing an FBA page. Instead, they get a basic authentication dialog box. If you are NOT using AD FS proxy, and you DO want FBA, carefully read through this article on the TechNet Wiki and decide if that is something you want to change. If so, you should be able to use the techniques outlined in this post to modify the ASP.NET pages on the AD FS server.

I had a chance to sit down and chat with Harold Wong, Senior IT Pro Evangelist for Microsoft on the Bytes by TechNet series recently. Here's the direct link: http://technet.microsoft.com/en-us/edge/bytes-by-technet-mike-pfeiffer-and-harold-wong.aspx and the video is embedded below:

The Bytes by Technet Homepage:
http://technet.microsoft.com/en-us/edge/bytesbytechnet.aspx

I'll be delivering another PowerShell.com PowerHour webcast later this month on 5/23. This time I'll be talking about Office 365 and PowerShell. Here is the description for the webcast: This webcast will help you extend your administrative capabilities in Office 365 with Windows PowerShell. Learn how to use the Microsoft Online Services Module for Windows PowerShell to provision accounts, manage licensing, and more. Find out how to perform common Exchange Online administrative tasks such as creating shared mailboxes, updating recipients, and assigning permissions. In this session you'll see several live demonstrations, and you'll walk away with code samples that will help you automate routine tasks in the cloud.

You can register for the webcast here.

I had a really great time presenting at the Spring 2012 Exchange Connections last month in Las Vegas. If you attended my sessions and want to download the materials, I've provided links to a zip archive for each presentation that contains the slide decks and sample code below.

CEM224: EMS Part I - Speed Up Your Work with the Exchange Management Shell
CEM325: EMS Part II - Exchange Management Shell Tactics from the Field

Feel free to contact me with any questions.

If you will be in or around Las Vegas at the end of March, come see me at the Exchange connections conference. I'll be talking about Exchange and PowerShell, but you'll also find a great mix of sessions for traditional Windows and Exchange Connections audiences, plus a great set of sessions on how to get to the cloud, if that is indeed where you need to go. I'll be presenting two sessions; a 200 and 300 level session on the Exchange Management Shell (EMS). The session abstracts are listed below.

EMS Part I - Speed Up Your Work with the Exchange Management Shell
Don’t let point and click administration in the Exchange Management Console slow you down. PowerShell command syntax can be intimidating at first, but once you understand some of the core concepts, you can vastly maximize your efficiency with the Exchange Management Shell (EMS). In this 200-level session, you will learn several techniques used to automate routine tasks and solve common problems that Exchange administrators are faced with on a regular basis. You’ll walk away with an understanding of how EMS works, and you’ll see live demonstrations showing you how to make bulk changes, generate reports and more. Administrators just getting started with the Exchange Management Shell will benefit from this session.

EMS Part II - Exchange Management Shell Tactics from the Field
Are you ready to take your Exchange Management Shell (EMS) skills to a new level? If you’ve been running Exchange cmdlets, or even doing some basic pipeline commands, you’ve probably already noticed an increase in efficiency. Now it’s time to turn up the heat. In this 300-level session, you will learn how to deal with common pitfalls and stumbling blocks that can arise when working with EMS in the field. You’ll also see how you can use PowerShell functions, scripts and one-liners to provide solutions to typical scenarios in real-world deployments. Exchange administrators that have some familiarity with PowerShell will get the most out of this session.

Check out the conference website for complete details and registration information. I'm really looking forward to it and hope to see you there.

It's easy to add one or more e-mail addresses to a recipient. This is usually done with an an e-mail address policy, or individually through EMC or EMS. The real challenge comes when you need to remove a specific address from a large number of recipients. For example, let's say that you use an e-mail address policy to add an addition e-mail address at contoso.com to every mailbox in the organization. If you later remove that domain from the policy, that won't go out and remove those addresses from your mailboxes. You have to do that manually. Below is code snippet you can use in EMS to remove addresses at a particular domain from every mailbox in the organization.

With Exchange 2010 SP1 or higher, you can take advantage of this special hash table syntax which is now supported with EMS cmdlets. It's keeps the code consise.

foreach($i in Get-Mailbox -ResultSize Unlimited) {
　 $i.EmailAddresses |
　　　 ?{$_.AddressString -like '*@contoso.com'} | %{
　　　　　 Set-Mailbox $i -EmailAddresses @{remove=$_}
　　　 }
}

This will simply iterate over each mailbox, and look for any address using @contoso.com. Any matches are removed. To use this code, just replace contoso.com with whatever e-mail domain you want to target. In this example, we're using Get-Mailbox to first retrieve all of the mailboxes. If you need to remove these address from groups, replace "Get-Mailbox" and "Set-Mailbox" with "Get-DistributionGroup" and "Set-DistributionGroup". This goes for other recipient types as well, such as dynamic distribution groups and mail users, etc.

So, you've just deployed Exchange UM and integrated it with Lync 2010, but you can't reach your voicemail. You've noticed that in the Lync Server event logs an event 44022 is logged and says something similar to the following:

The attempt failed with response code 504: EX2010.uss.local.
Request Target: [UMDP@EX2010.uss.local], Call Id: [026e7750cea5472296affeae0240ac4b].
Failure occurrences: 2, since 1/10/2012 12:28:50 PM.
Cause: An attempt to route to an Exchange UM server failed because the UM server was unable to process the request or did not respond within the allotted time.

Resolution:
Check this server is correctly configured to point to the appropriate Exchange UM server. Also check whether the Exchange UM server is up and whether it in turn is also properly configured.

Don't worry, it's an easy fix. Most likely, it's caused by an incorrect subject name on the Exchange UM server certificate. Check the certificate in EMC, or fire up EMS and run the Get-ExchangeCertificate, targeting the UM server:

Get-ExchangeCertificate -Server ex2010 | fl subject,services

You want to make sure the certificate on the UM server is setup like this one. For example, my UM server name is ex2010.uss.local. This needs to be subject name on the certificate—in other words, it needs to be set as the common name when you generate the certificate request. Also, the UM service needs to be assigned to the certificate.

If either of these are off, you'll need to fix them. To assign the UM service to a certificate in EMC, just right click the certificate and select 'Assign Services'. This will take you through a wizard where you can assign the UM service to the certificate. If the subject name is wrong, that will require a little more work, and you will need to generate a new certificate. After making these changes, restart the MSExchangeUM service and you should be all set.

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.