PointBridge Blogs - Jeff Schertz

Outlook Profile Configuration without the MSOL Client

By: Jeff Schertz Posted: February 7, 2010 at 11:10 AM

There are a few scenarios where you may want to use Outlook to access an Exchange Online mailbox but cannot use the Microsoft Online Services Sign-In client. This could be due to installation or operating requirements of the client (some OS versions are unsupported) or maybe users don’t have the required permissions to install software but can at least modify Outlook profiles.

Take note that this is a completely unsupported approach and might not even work on some platforms. The intent is for accessing the mailbox in temporary situations and not for long-term deployment solutions. Not using the sign-in client can impact more than just single-sign-in user experience. It is a ‘best practice’ approach to deploy the client to end-users on supported platforms.

The instructions in this article are simply a reverse-engineered look at what it is required to configure an Outlook profile to work with a mailbox hosted on Exchange Online/BPOS. This approach was tested using Outlook 2003, 2007, and 2010 against a mailbox hosted in the North American datacenters. I assume the same process would also work for other regions of the world with the correct URLs (red002 for EMEA and red003 for APAC).

The two main issues that can prevent administrators from successfully configuring profiles are related to (a) the order in which the profile is configured and (b) the confusing nature of the Exchange mailbox server names. But using the correct approach to the first issue takes care of the second.

Create New Outlook Profile

Start by creating a new Outlook profile using the Mail control panel applet. (In Windows 7 this can be found by searching for ‘mail’ in the Control Panel window.)

Open the Mail (or "’Mail 32-bit’) Control Panel applet.
Click Show Profiles…
Click Add…
Enter a unique, descriptive name for the new profile (e.g. jeff@contoso.com)
Depending on the version of Outlook used select the available choice to create a new profile:

Outlook 2003: Add a new e-mail account
Outlook 2007/2010: Manually configure server settings or additional server types

Select Microsoft Exchange (Server).

Now the first important step has been reached, as a valid server name will need to be supplied, but the odd thing is that internal, non-resolvable FQDNs are used by for the Exchange Online mailbox servers. If you have ever looked at a profile configured automatically by the sign-in client you would have noticed that the server names were typically in a REDxxx.local domain. So clearly a normal connection cannot be made to that server over the Internet as .local is not a publically supported DNS suffix. But Outlook Anywhere (aka RPC over HTTP) can be configured for the initial connection to the mailbox. This approach also works for all on-premise Exchange clients as well when trying to configure a profile to use Outlook Anywhere when Autodiscover is either not configured or supported.

There is a long list of possible Exchange mailbox server names that may change at any point as since this is an unsupported process Microsoft could modify them at any point during server upgrades/replacements. The name used in this example the may not work so I would recommend looking at the profile setting of another mailbox (or even the same mailbox) which was configured properly through the normal client procedure. If that mailbox server name resolves but is not the server which actually hosts this specific mailbox account the profile will still work as Exchange will redirect Outlook to the correct mailbox server in the organization. This can be verified by seeing that the server name changes to a different value after the profile is initially setup.

Enter VA3DIAXVS101.RED001.local in the Microsoft Exchange server field. Verify that Use Cached Exchange Mode is selected.
Enter the username of the desired mailbox, e.g. jeff@contoso.com or jeff@contoso.microsoftonline.com, whichever format is the configured username of the online account.
Click More Settings…
An error message will appear stating “The action cannot be completed. The connection to Microsoft Exchange in unavailable. Outlook must be online or connected to complete this action.” Click OK.
Another settings window labeled Microsoft Exchange will appear. Click OK again.

Note: If you attempt to use the Check Name button in the previous window the process will always fail as the .local server name is not yet resolvable. Ignore that button.

At this point the profile settings window should be displayed as seen in the image below, allowing the remainder of the configuration to be completed manually. This allows for the RPC over HTTP settings to be configured so that the once unresolvable .local server name will now be valid.

Configure Profile Settings

Enter and confirm the following settings across the various properties tabs. All steps beginning with ‘Verify’ or ‘Confirm’ indicate that the default value is the desired setting. Steps labeled as ‘Select’ or ‘Enable’ indicate a change in the default profile setting.

General Tab

Enter a descriptive account name (e.g. Exchange Online).
Select Automatically detect connection state.

Advanced Tab

Verify that Used Cached Exchange Mode and Download shared folders are enabled.

Security Tab

Verify that Encrypt data between Microsoft Office Outlook and Microsoft Exchange is enabled.
Verify that Negotiate authentication is the selected Logon network security setting.

Connection Tab

Enable Connect to Microsoft Exchange using HTTP.
Click Exchange Proxy Settings…

Exchange Proxy Settings

In the Use this URL to connect to my proxy server for Exchange field, enter red001.mail.microsoftonline.com for mailboxes stored in North America datacenters. Substitute red002 or red003 for other regions.
Enable the Only connect… or Mutually authenticate… setting (depending on the version of Outlook).
Enter the proxy server value of msstd:*.mail.microsoftonline.com in the field below.
Enable the setting On fast networks connect using HTTP first, then connect using TCP/IP.
Verify the setting is enabled for On fast networks connect using HTTP first, then connect using TCP/IP.
Verify that NTLM Authentication is the selected Proxy authentication setting.

Once completed with the steps above click OK to close and save the profile window, returning back to the original account creation wizard.

Click the Check Name button next to the User Name field and an authentication prompt should appear. Enter the password for the online account.

After a few seconds the Microsoft Exchange settings page on the wizard should have updated the information by updating the correct home mailbox server name as well as converting the username to the Display Name value. The underlined text format in both fields indicates a successful connection to the online mailbox, and thus the profile configuration is complete.

Click Next and Finish to complete the wizard.

Back at the original Mail applet window make sure that the Prompt for a profile to be used setting is enabled if there are now multiple Outlook Profiles configured on the same Windows user profile.

To DirSync or not to DirSync

By: Jeff Schertz Posted: January 29, 2010 at 8:00 AM

When setting up a new BPOS site for clients the first conversation I make sure to have is about their on-premise Active Directory solution. Most companies already have a domain even if they are currently using Notes or Groupwise for a messaging solution, I haven’t seen a fully native Novell operation where no Windows domain authentication is in place in quite a long time. But often in the midst of messaging migrations there is also some type of Active Directory transition planned or in progress.

Depending on the size of the company and the schedule for testing, piloting, and migrating one must decide what approach to use to populate objects into the online directory. In the past this was limited to one of two options for BPOS, either manually creating user accounts through the Microsoft Online Services Administration Center (MOAC) or establishing Directory Synchronization in an on-premise Active Directory forest. Both approaches have benefits and drawbacks, but almost 100% of the time Directory Synchronization is used due mainly to the reduced workload in initially getting account established online and the added management features and control offered.

Now that a host of new PowerShell-based cmdlets have been added to the Migration Command Shell (previously discussed in this article) there is a third approach that can be used which falls in the middle of the previous choices. Before if you had a customer not planning or able to use Directory Synchronization but had more than ~50 users then setting up the users, groups, and contacts manually via MOAC could be an arduous task. In these cases MOAC does allow for specially formatted CSV files to be used to bulk-create user accounts, but this process can be very slow when used for hundreds of accounts and often took hours and multiple stages to complete. Also groups and contacts must still be created one at a time, no import process exists in MOAC to do this today.

So what I used to do was setup a temporary AD domain in a virtual lab and then import all the objects via CSVDE or LDIFDE scripts and then establish a one time DirSync process to populate all the objects. The downside to using this solution was that each object created would be stamped with an ObjectGUID specific to that Directory Synchronization deployment matching everything back to what would be temporary objects in a temporary AD forest. After the initial sync the source environment was torn down and DirSync disabled. The danger here is that if the company later wanted to establish synchronization with a future AD forest they may be planning to deploy then the existing objects would not be available to match as their GUIDs were already stamped with a value.

But this approach is no longer needed as you can now go straight from similar CSV import files into the online directory using the Add-MSOnlineUser cmdlet. What I recently discovered though is that this new command emulates a manual synchronization process, in that you must first enable Directory Synchronization on the site before the cmdlet will function correctly:

This lead me to realization that if the cmdlet is emulating a Directory Synchronization process, does this mean we will run into the same problem regarding populated GUIDs? Unfortunately, yes. When the account is created via the cmdlet the ObjectGUID is stamped with a ‘fake’ value which means that later attempts to match these accounts with an on-premise directory will not work.

So the general approaches are:

If there is any chance that a company may want to or need to utilize Directory Synchronization in the future to manage objects with an on-premise Active Directory forest, then do not initially populate objects into the cloud using either a temporary DirSync process nor the Add-MSOnlineUser cmdlet. Only use MOAC to either manually create objects or import them from a CSV file.
But if there is no chance that Directory Synchronization will ever be used then either manually create objects in MOAC or use the Add-MSOnlineUser cmdlet.

It is worth noting that if accounts are created via MOAC using an import script (or established via DirSync) the new Enable-MSOnlineUser cmdlet can still be used to activate the accounts in bulk instead of performing this manually in the console. This is a huge time saver as the console only allows a handful of users to be enabled at a time and each user can take 15-60 seconds to activate. Using the cmdlet is typically much quicker in that all accounts can be processed in one script and the individual execution is faster.

Understanding Contact Objects in Exchange Online

By: Jeff Schertz Posted: January 8, 2010 at 8:15 AM

When planning a migration up to Exchange Online, or even when working with a current customer that has already noticed this, there is one important distinction to be aware of regarding how Contact Objects are handled in the BPOS-Shared realm. Whether or not Directory Synchronization is (or will be) used with an on-premise Active Directory domain is also important.

Created in the Cloud

First off, an administrator can simply create a contact directly in the Exchange Online environment using the Microsoft Online Services Administration Center (commonly referred to as MOAC). The primary purpose of a contact object in Exchange is to include a single managed object which appears in the global address book to all users for sending email to an external SMTP address. A contact can not use an internal SMTP address in any domain, meaning that any domain which is currently verified in BPOS as Authoritative and configured for Inbound Messaging should not exist in a contact. Otherwise a Non-Delivery Report (NDR) would be created if any internal users attempt to send a message to it. Any foreign domains and any BPOS-verified domains still configured for External Relay would still be allowed.

Assuming we have a BPOS-Shared site of schertz1.microsoftonline.com let us create a new contact for my PointBridge email address. Using MOAC, the following contact was created directly in the cloud; no Directory Synchronization was used in this process (more on that later).

Once the contact is created it appears in the Contacts list with the SMTP address I added above:

But here where things get a little different. With a standard On-Premise Exchange deployment that exact address would appear in the address book in Exchange, but due to the fact that BPOS-Shared uses a single multitenant directory for separate clients there needs to be a way to store the address in a globally unique format. Otherwise if another BPOS-S client had already created a contact for the same SMTP address in their directory then we would have received an error when attempting to add this contact.

A quick peak at the Address Book in Outlook shows the actual format that the SMTP alias is stored in the directory:

By using this shadowed format the same SMTP alias can be stored in multiple tenant directories without conflict as the site’s specific (and unique) default domain name is used as the suffix. Regardless of how the SMTP alias appears in the address book to users the functionality is still the same and all messages sent to the contact are delivered to the correct address.

Directory Synchronization

The main difference here is when a contact object is created in BPOS by Directory Synchronization instead then the displayed E-mail alias will not look the same as what was shown above. When viewing the proxy address from either the administrative console or an Outlook client a different format appears, which upon first glance appears to be completely incorrect.

In this example there is a contact stored in an on-premise AD domain for Matt McGillen which contains his PointBridge SMTP address:

But when this object is created in BPOS via Directory Synchronization it appears to be stamped with a different address of mmcgillen@schertz1.microsoftonline.com which uses the default mail routing domain name in this BPOS site. This address appears the same anywhere it can be viewing in Exchange.

From the Contacts list in the Microsoft Online Service Administration Center:

From the E-Mail Address tab of a user in the Outlook Address Book:

From the online Address Book view in Outlook Web Access:

Obviously if this was the real address stamped on the contact it would no longer work as a mail forwarder as that domain is (by default) configured as an internal relay domain in BPOS and clearly wouldn’t send messages to the proper mailbox. But the contact will, and does work as expected. What happens is although the same shadowed proxy address format as described earlier in this article is used on the contact object itself to allow for unique address across the multi-tenant domain, the actually displayed format of that address does not reflect that.

The functionality is the same whether the contact was created manually in MOAC or automatically via Directory Synchronization, but the addresses are displayed to the administrators and end-users differently. I was told by Microsoft this caveat was necessary in order to get the proper functionality, but unfortunately the shadowed proxy address is not displayed for the synchronized contacts.

So, in a smaller environment it can sometimes be a better solution to leave the contacts out of AD (if possible) and simply create and manage them in MOAC. This will allow end-users to see the proper SMTP aliases and be less-confusing to them. Otherwise simply make sure that at least your administrators are aware of the display issue in the case any migrated end-users start to notice it and question the validity of the contacts. It is still undetermined if this behavior will be changed in the future to display the correct address for synchronized object.

Retrieving the Mailbox Size in BPOS

By: Jeff Schertz Posted: January 7, 2010 at 4:38 PM

(Okay, before I get hate mail for two iPhone related blog articles in a row let us get back to business).

One of the more common questions I get when migrating clients up to Exchange Online is where can they view mailbox size information for all of the users online. This is typically more often asked during Exchange on-premise migrations where administrators are used to being able to retrieve that information from the Exchange Command Shell.

Unfortunately the Microsoft Online Services Administration Center (MOAC) does not show this information anywhere in the online console, but it can be retrieved for hosted mailboxes in BPOS by using the Migration Command Shell.

If you haven’t already downloaded these tools, you should. Even if you don’t require the Migration Console for moving mail from an on-premise Exchange or hosted IMAP/POP mail server, the Migration Command Shell is an very handy tool for any BPOS customers both during migration and afterwards for managing the environment. There are a number of features that previously were either unavailable in BPOS or required a service ticket to be opened to be accomplish, yet now are available directly to the administrator via PowerShell cmdlets.

The toolset can be downloaded in either a 32-bit or 64-bit version directly from either of these links and installed on either desktop or server operating systems. You may also need to install the prerequisite PowerShell 1.0 software depending on the current operating system.

Microsoft Online Services Migration Tools (32-bit)
http://www.microsoft.com/downloads/details.aspx?familyid=9ed5f4c1-7f0b-4506-a214-32093af6147a&displaylang=en

Microsoft Online Services Migration Tools (64-bit)
http://www.microsoft.com/downloads/details.aspx?familyid=5547634C-5E49-4DBD-B6B0-457B38A75F33&displaylang=en

Once the tools are installed check ‘All Programs’ for the shortcut at Microsoft Online Services > Migration > Migration Command Shell. Once the command is launched the easiest way to retrieve data like the mailbox size is to use a pair of commands: one to temporarily store your administrator credentials and another to lookup a specific mailbox. Then the second command can be re-run on other users without having to continually re-enter your credentials.

The Cmdlets

Start with the first cmdlet which creates a variable ($cred) and then prompts for a username and password to store. Any account which is configured as an administrator in BPOS would be entered here.

$cred = Get-Credential

Then the main cmdlet is used to check a specific user account and call the previously stored credentials to be used to authenticate against Exchange Online. Only the –SourceIdentity value needs to be set differently than this example as all North American BPOS customers would use the alias red001.mail.microsoftonline.com to make the WebDAV connection to. (EMEA customers would use red002 and APAC customer red003.) The SourceDetail switch is very important as without it connection will be not be attempted and the cmdlet will appear to work but just a bunch of default and null values will be returned.

Get-XsHostedExchangeMailbox -SourceServer red001.mail.microsoftonline.com -SourceIdentity jeff@schertz1.microsoftonline.com -SourceAdminCredential $cred -SourceDetail Full

Highlighted above are the StorageByteSize and ItemCount values for the queried mailbox.

Eventually the Get-MSOnlineUser cmdlet is supposed to be updated to return this information, which will make it even easier (and faster) since it will use native MSOL technology instead of WebDAV to retrieve the information.

BPOS Sign-In Client Breaks iPhone USB Synchronization

By: Jeff Schertz Posted: January 7, 2010 at 4:18 PM

So, I just ran into this issue and thought it would be worth documenting. During countless pilot migrations of users from various mail platforms to the Exchange Online portion of BPOS I’m surprised I’m just seeing this for the first time.

The Scenario

Where this appears is with a standard end-user scenario of a single Microsoft Outlook profile configured for POP or IMAP access to some hosted mailbox. Also iTunes is installed on the same computer and the iPhone is configured to synchronize Contacts, Calendar items, Email messages, etc over a USB connection.

If the Microsoft Online Services Sign-In client is installed and configured on the computer, one of the things the application configuration for Outlook does is create a new Outlook Profile for the online mailbox, leaving the existing profile alone. But it also deselects a default profile and configures Outlook to prompt for a profile when launched. This prompt is later hidden from BPOS users when they launch the application from within the Services Sign-In client itself, but is visible when Outlook is launched directly from Windows via a desktop shortcut or any other application shortcut outside of the Services Sign-In client.

Here is how the Mail control panel would be configured before the installation of the Service Sign-In client:

And this is what the configuration would look like after the Services Sign-In client configures Outlook:

What I discovered is that iTunes is not compatible with multiple Outlook profiles and will only synchronize with the profile configured as the default. So in this scenario where there is no longer a default profile chosen the next device synchronization would actually remove all Outlook content from the phone! Whoops.

The Workaround

This scenario typically would only happen during pilot or testing phases were a user might be logging into both the source and target mailboxes at different times on the same computer. Once the user is migrated over to Exchange Online then the iPhone would be reconfigured to use Exchange ActiveSync and no longer could iTunes be used to synchronize mailbox content to the device.

But until the user is migrated, if they need to restore the source mailbox data to the iPhone then the following steps can be used:

Select a Default Profile

Close Outlook, iTunes, and disconnect the phone.
Open the the Mail control panel applet, also called Mail (32-bit) in 64-bit operating systems.
In the Mail - Setup window click on the Show Profiles… button.
Change the When starting Microsoft Outlook, use the profile setting to Always use this profile and then select the original profile, which is typically named ‘Outlook’. Do not select the profile named after your BPOS account’s email address.

Resynchronize the iPhone

Launch iTunes with the iPhone not connected to the computer.
Go to the Edit menu, select Preferences… and then select the Devices tab.
Click the Reset Sync History button, then click OK to close the Preferences window.
Connect the iPhone via USB and sync the device and all of the mailbox content should begin to copy to the device.
Disconnect the iPhone and verify that all missing mailbox data has been restored to the device.

From this point, one of two choices are left. The supported answer would be to revert Outlook back to no default profile and then not synchronize the device again until the mailbox migration is complete. On the other hand, the changes could be left as-is and although the Services Sign-In client will appear to function correctly it is possible that be having that unsupported configuration other problems could arise over time.

Quick Launch
View All Site Content

About Jeff Schertz

Tag Cloud

Blogroll

‭(Hidden)‬ Admin Links

Quick Launch View All Site Content

About Jeff Schertz

Tag Cloud

Blogroll

‭(Hidden)‬ Admin Links

Quick Launch
View All Site Content