MessageOps Microsoft Online Blog

If you are running Directory Synchronization, you probably know the basics of what attributes are synchronized from your local Active Directory to Microsoft Online. Things like names, group membership, address and contact information are all synchornized. In this post we'll take a look some of the more unusual, but very useful attributes, that are synchronized to Microsoft Online.

Before we get started it is important to note that the majority of these attributes will only appear in your Active Directory if you have the schema extended for Exchange.

First let's take a look at the interesting attributes which you can set on user objects:

msExchHideFromAddressLists
Setting the msExchangeHideFromAddressLists attribute to True on an object in your local Active Directory will hide it from the Global Address List in Microsoft Online. This also applies to Groups.

TargetAddress
If the account is enabled in Microsoft Online, you can set the TargetAddress of the object in your local Active Directory. Setting the target address on an objects redirects all mail sent to that object to another address. You can even use this to redirect mail to an external recipient. For those of you not familiar with the TargetAddress attribute, the format is SMTP:user@domain.com. A word of warning on this attribute, this probably isn't supported, as things like mailbox moves do wipe out targetaddresses on mailboxes, so use this with extreme caution.

Groups have a few more attributes that you can modify in AD:

(This information is from the very useful BPositive Blog)

AuthOrig (Authorized Originators: Only these Users can send to the DL)
UnauthOrig (Unauthorized Originators: Anyone BUT these users can send to the DL)
dLMemRejectPerms (Unauthorized DLs: Anyone but members of these DLs can send to this DL)
dLMemSubmitPerms (Authorized DLs: No one but members of these DLs can send to this DL)
msExchRequireAuthToSendTo (Only Authenticated Senders can send to the DL, blocks External senders)

The attribute that most people typically want to modify is AuthOrig. That will allow only those users specified to send to the DL. If you don't have Exchange Management Tools installed, the tricky part is when populating the attribute in AD you have to enter the Distinguished Name of of the object you want to give the right to. To get the DN you’ll have to open the user you want to give rights to in ADSIEdit and copy the Distinguised Name Attribute out. The DN will look like:

CN=Bob,OU=Users,DC=Dev,DC=Local

You then enter that value in the AuthOrig attribute on the Group. When complete only Bob will be able to send to that DL.

The other common attribute that people set is msExchRequireAuthToSendTo. If this is set to False or Not Set in your local Active Directory the check mark in the "Allow External Senders" checkbox will be checked in the Microsoft Online Administration Console. Setting it to True in your local Active Directory will cause the checkbox to be Checked in Microsoft Online.

For the dLMemRejectPerms and dLMemSubmitPerms, you must enter the DN(s) of the Group(s) that you want to deny or grant access to.

Additional Attributes you can set are:

hideDLMembership
Setting this attribute to TRUE on a group in your local Active Directory will hide the group membership in Microsoft Exchange Online.

ManagedBy
This is another attribute that you must populate with the DN of the object you want to use. In this case the user specified in the ManagedBy attribute in AD will appear as the owner of the group in Exchange Online. Unfortunately, this does not allow the user to update the group's membership in Exchange Online.

For additional information about what information is sychronized with Microsoft Online Directory Synchronization, you can request a copy of MessageOps Directory Sync In Depth Whitepaper.

This error has stumped me for the past couple weeks so I had to write a post when I finally figured it out. Here's the basic scenario. You install the Microsoft Online Migration Tools on a server and when someone logs into the server and issues any of the Microsoft Online PowerShell commands, they get an error which states:

Object reference not set to an instance of an object

After much trial and error I was able to figure out this error is caused by the Internet Explorer settings. It appears you have to configure Internet Explorer before you can run the Microsoft Online PowerShell commands. In my cases, the users that couldn't run the commands were users who had logged into the server for the time, and thus IE was not configured. The fix was to open IE and run through the configuration wizard.

If simply opening IE and configuring the settings doesn't work for you, you can try these steps to reset the IE configuration:

To use the Reset Internet Explorer Settings feature from Control Panel, follow these steps:
1. Exit all programs, including Internet Explorer (if it is running).
2. If you use Windows XP, click Start, and then click Run. Type the following command in the Open box, and then press ENTER:

inetcpl.cpl

The Internet Options dialog box appears.

3. Click the Advanced tab.
4. Under Reset Internet Explorer settings, click Reset. Then click Reset again.
5. When Internet Explorer finishes resetting the settings, click Close in the Reset Internet Explorer Settings dialog box.
6. Start Internet Explorer again.

Then, if it's still not working:

1. Right Click on the Command Prompt Shortcut on the Start Menu and Choose Run As Administrator.
2. In the Command Prompt window, enter this text and press Enter:

regsvr32 actxprxy.dll

3. Restart your computer.

In Microsoft Exchange Online when configuring Conference Rooms through the Administration Console, the options are pretty basic. You can configure whether or not to automatically accept meeting requests or have them approved by a Delegate. If you want to make futher modifications, you can, but you must log in through Outlook Web Access. Since it's a resource you can't log directly into the mailbox via OWA, you need to first log into OWA using an account which has Service Admin rights in Microsoft Online. You can then open the resource mailbox as shown in the image below.



Once in the resource mailbox, go into Options and in the left pane you'll see Resource Settings. Clicking on Resource Settings will reveal many more options that can be used to customize the behavior of the resource mailbox as shown in the image below.

On 1/11/2010 mail delivery was delayed was for some Microsoft Online Clients.

Source:

http://rss.messaging.microsoft.com/network_alerts.xml

In most cases the delays weren't that bad, but the MessageOps Exchange Online Monitor (Exmon) did catch these delays early on and record some interesting information. Probably the most interesting was the average round trip time for they day. Typically the daily average is around 20 seconds, but on the 11th it was over 300 seconds.



The other interesting thing was that Exmon started reporting alerts around 10 AM EST on the 11th. At that point, it appears that some of the messages starting getting delayed. Out of the roughly 30 messages that Exmon was sending an hour it appears that around 5 an hour were delayed. So if you had Exmon configured and running in your environment it's likely you would have known there were issues before the formal notification went out in the afternoon.

For more information about Exmon, visit http://www.messageops.com/ExmonDownload.html

If you've setup Microsoft Online Directory Synchronization in many different environments, chances are you've come across this error more than once when configuring Directory Synchronization for the first time:

Set-CoexistenceConfiguration was unable to modify the source properties. See the event logs for more detailed information.

Upon examination of the event log, you'll probably see a sequence of events similar to:

Event Type: Warning
Event Source: Directory Synchronization
Event Category: None
Event ID: 0
Date: 8/2/2009
Time: 1:34:59 PM
User: N/A
Computer: MSONLINE
Description:
Resetting password for MSOL_AD_Sync

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type: Error
Event Source: Directory Synchronization
Event Category: None
Event ID: 0
Date: 8/2/2009
Time: 1:35:00 PM
User: N/A
Computer: MSONLINE
Description:
A constraint violation occurred. (Exception from HRESULT: 0x8007202F)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type: Error
Event Source: Directory Synchronization
Event Category: None
Event ID: 0
Date: 8/2/2009
Time: 1:35:00 PM
User: N/A
Computer: MSONLINE
Description:
Set-CoexistenceConfiguration was unable to modify the source properties. See the event logs for more detailed information.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Unfortunately, the "constraint violation occurred" message really doesn't give you a good idea of where the problem lies. Sure, it's typically permissions, but how can you tell for sure?

With the recent addition of the Get-MsOnlineUser commandlet, it is now possible to create a PowerShell script which automatically notifies users when their Microsoft Online passwords are about to expire. This is huge feature, especially for deskless workers, since up until now there hasn't been a good way to let them know when their passwords are about to expire. Below is a script to automatically notify users of their upcoming password expiration, but first is quick overview of how it works.

You must first configure when you want to start notifying users that their Microsoft Online password is about to expire. The default is 15 days. If the script is scheduled to run nightly, 15 days from the date the user's password is set to expire, they will be sent an email which by default looks like:

Message Subject: ACTION REQUIRED: Your Microsoft Online Password will expire in 15 days

Message Body: Your Microsoft Online password will expire in 15 days. Please use the Microsoft Online Sign in Client to change your password. If you do not use the Sign In Client, browse to https://home.microsoftonline.com to reset your password.

If they don't change their password, the script will run again the next night and notify them that they now have 14 days left to change their password. It will continue to do this every day until they change their password.

Below is the script. Make sure you modify the appropriate variables and test it on a single user before running it against everyone in your environment. If run improperly it has the potential to really confuse the end users, so please contact MessageOps, at support@messageops.com, if you have any questions prior to running it. We'll be glad to help you implement or customize the script in your environment.

You can download the properly formatted script here.


#Microsoft Online Password Expiration Notification Script
#
#Written By:Chad Mosman, MessageOps, www.messageops.com
#
#This script notifies users via email when their Microsoft Online Password is about
#to expire. It is designed to be scheduled to run on a daily basis. Due to the way
#it searches for users, it requires directory synchronization be enabled for the domain
#it is run against.
#
#The following variables should be modified before running the script
#
#$AdvancedWarning - Controls how many days before expiration the users will be notified
#that their password is about to expire. Default is 15 days.
#
#$mailFrom - Enter the email address that the notification will appear to come from.
#
#$SMTPServer - If inbound mailflow is enabled for your Microsoft Online domain, the default of
#mail.global.frontbridge.com should work. Otherwise, specify the name of your on-premise
#mail system.
#
#$powerUser - Username of an account with Service Admin Rights in Microsoft Online.
#
#$powerpass - Password of the account with Service Admin Rights in Microsoft Online.
#
#$subject, $body - The notification message subject and body can be customized to your needs.
#
#When testing it is recommended the script be run against a single user. To do that, change:
#
#$collitems = Get-XsActiveDirectoryUser -Identity *
#To
#$collitems = Get-XsActiveDirectoryUser -Identity EmailAddressOfTestUser
#
#For assistance with the script, to report problems, or provide comments contact support@messageops.com
#

#Number of days in advance the user should be warned that their password is about to expire
$AdvancedWarning=15

#Email address that the notification email will appear to be from
$mailFrom = "user@yourdomain.com"

#If inbound mailflow is not enabled on your domain in Microsoft Online, change this value
#to your on-premise mail server which should forward to Microsoft Online
$smtpServer = "mail.global.frontbridge.com"

#Microsoft Online Service Account Username and Password
$powerUser = "user@domain.microsoftonline.com"
$powerPass = "Password"

$password = ConvertTo-SecureString $powerPass -AsPlainText -Force
$adminCredential = New-Object -TypeName System.Management.Automation.PSCredential -argumentlist $powerUser,$password

#Get all objects in your local Active Directory that are synchronized to Microsoft Online
$collitems = Get-XsActiveDirectoryUser -Identity * -Resultsize 100000 -quiet| Search-XsMicrosoftOnlineDirectory -Credential $adminCredential

foreach ($objitem in $collitems){

#Determine if the user has been activated or not
if($objitem.HardMatchName -ne $null){
$mailbox = get-xshostedExchangeMailbox -SourceIdentity $objitem.HardMatchName -sourceserver domain.com | Search-XsMicrosoftOnlineDirectory -credential $adminCredential

#check to see if the account is activated
if($mailbox.TargetSendQuota -gt 0){

#format the email address
$emailAddress = $mailbox.HardmatchName -replace "SMTP:",""

#get the password expiration date for the current user
$user=Get-msonlineuser -identity $emailAddress -credential $adminCredential

#calculate the date difference between today and the password expiration date
$datedifference=($user.PasswordExpirationDate-[DateTime]::Now).Days

#is the password going to expire withing the number of days configured in the AdvancedWarning?
If ($datedifference -le $AdvancedWarning){

If ($datedifference -eq 0){
$subject = "IMMEDIATE ACTION REQUIRED: Your Microsoft Online Password Has Expired"
$body = "Your Microsoft Online password has expired. "
}
ElseIf ($dateDifference -eq 1){
$subject = "IMMEDIATE ACTION REQUIRED: Your Microsoft Online Password will expire in 1 day"
$body = "Your Microsoft Online password will expire in 1 day. "
}
Else{
$subject = "ACTION REQUIRED: Your Microsoft Online Password will expire in",$datedifference,"days"
$body = "Your Microsoft Online password will expire in",$datedifference,"days. "
}

$body = $body + "Please use the Microsoft Online Sign in Client to change your password. If you do not use the Sign In Client, browse to https://home.microsoftonline.com to reset your password."

#send notification to user
$smtp = new-object Net.Mail.SmtpClient($smtpServer)
$smtp.Send($mailFrom, $emailaddress, $subject, $body)

}
}
}
}



If you are going to use the Enable-MSOnlineUser command to bulk Activate users in Microsoft Online, one of the parameters you must specify is the UsageLocation. The only details the help file gives on the UsageLocation parameter is:

The location of the user—the location you select determines the available services. Currently the Cmdlet only accepts two-character country codes. It cannot activate users with three-character ISO country codes.

The documentation falls a little short on what the available country codes are. After doing some testing, it appears that the following list:

http://www.iso.org/iso/english_country_names_and_code_elements

contains the 2 character country codes you can use for the usage location. Obviously we weren't able to test all the country codes, but from the 10 or so we did, all appeared correct in the Administration console after activing the users via PowerShell.

Given the high number of downloads of Exmon from people around the world, we wanted to take some time and explain how to configure Exmon to work with the Microsoft Online Datacenters outside of the US. In the very near future this will be part of the program, but for now you'll have to modify the configuration file if you want to use it against the EMEA or APAC datacenters.

First, you must open the Exmon.exe.config file located in the Program Files\Exmon Directory. Near the bottom of the file you should see a section, which looks like:

< applicationSettings >
< Messageops.ExMon.Properties.Settings >
< setting name="Server" serializeAs="String" >
< value>red001.mail.microsoftonline.com< /value >

You will need to replace red001.mail.microsoftonline.com with the appropriate server, based on your location:

APAC - red003.mail.apac.microsoftonline.com
EMEA - red002.mail.emea.microsoftonline.com

After making the change you can then save the configuration file and restart the program.

The remaining changes can be made in the GUI.

If you want to use the Bulk Login test you should replace the existing mail.microsoftonline.com with the appropriate server based on your location:

APAC - red003.mail.apac.microsoftonline.com
EMEA - red002.mail.emea.microsoftonline.com

If you want to use the Network Latency, you should replace the echova3.microsoftonline.com with the appropriate server, based on your location:

APAC - echosg1.microsoftonline.com
EMEA - echoIE2.micorosftonline.com

A future release of Exmon will include the ability to choose your location which will automatically configure the appropriate settings.

Lately we've done a few migrations for clients who have their email currently hosted by a Microsoft Exchange hosting provider and want to move to Microsoft Exchange Online. These migrations have presented a few unique challenges, so we thought we'd share our experiences.

One of the biggest challenges you face right from the start is determing how to gain access to the mailboxes. Ideally you'd have an account which has access to all your organization's mailboxes on the source server. Some hosting providers can set that up, others can't or won't. If you are unable to get an account which has access to all the mailboxes you need to migrate, you will need to know all the individual user's passwords to gain access to their mailbox. This can typically be accomplished in one of two ways. You can either ask the users for their password or you can reset the user's passwords, so you know what the password is set to. If you have a very small number of users, you might be able to round up all the passwords, but in most cases, you'll probably need to develop a migration plan which resets the users when they are migrated. In some cases, this could have the added benefit of denying the user access to the source mailbox after they have been migrated.

The next challenge you face is coexistence. Again, a lot of things depend on what is possible with your current hoster, in this case it's whether or not they'll let you setup forwarders on the mailboxes. If they do let you setup forwarders, you'll typically need to create contact objects which have a target address of user@company.microsoftonline.com. Right before you get ready to migrate a user, you will go in and manually set the forwarder on their account and then begin the migration. This ensures all new mail sent to their mailbox will be delivered to their Microsoft Online Mailbox. If they don't let you setup forwarders, it gets a little trickier. Basically that all but forces you to do a one time cutover. If you don't do a one time cutover, mail sent from an unmigrated user to a migrated user will be delivered to the migrated user's mailbox on the source server since forwarding is not in place.

If you are going to do a one time cutover it's very important that you test the throughput of the migration tools prior to the migration. You might discover that's it's simply not possible to migrate all data over the course of a weekend and you instead need to migrate a subset of data, such as calendar and contacts. Once those items are complete you can begin moving the mail data in stages. Maybe the first run would be all mail newer than 7 days. The second run new mail newer than 30 days. The final run everything old than 30 days. Other options include having users archive more of their mailbox to PST. If your bandwidth seems to be the bottleneck(mail has to be copied from the hosting provider to the migration workstation and then to Microsoft Exchange Online) contact MessageOps about using our datacenter access to host your migration workstations so the traffic goes from the current hosting provider to the datacenter and then to Microsoft Online....the traffic doesn't have to go over your local network.

Another consideration if doing a one time cutover is the OST rebuild. If you migrate all the users over a weekend and they are in cached mode, on Monday morning they are all going to have to download all their mail to rebuild their Outlook OST file. This can often times bring an organization's internet connection to a halt.

These are just a few things to consider when moving from your current hosted Exchange environment to Microsoft Exchange Online. If you have any questions or would like free assistance with your migration, please contact us at www.messageops.com

One commonly used feature of Exchange that Microsoft Exchange Online does not support is the ability to have multiple address books. Companies use seperate address books to segment users by location, department, or even house external recipients. There are a several different ways to go about creating this same functionality with Microsoft Online. We'll explore a couple different options. First, if you have purchased SharePoint Online, you can create a SharePoint list containing contacts. If you don't have SharePoint, another more complicated way to work around this limitation is to use the LDAP address book functionality in Outlook along with your local Active Directory.

First we'll demonstrate the SharePoint method as it would be the preferred method in most cases. Step 1 is to create a Contact List within SharePoint. From the Actions Menu choose Create. Then choose Contacts under the Communications category.



After it has been created, you can begin entering the contact information in SharePoint.



Once the information is in SharePoint, you will need to connect the list to Outlook. From the Actions Menu choose Connect to Outlook.



Once connected to Outlook, you will be able to go to Contacts and see the SharePoint contact list as show below.



The contacts will also be availble when opening the Address Book.



If you haven't purchased SharePoint Online, there is another method to create multiple address books when on Microsoft Online. It's a lot more complicated, but is an option if you really need multiple address books. This option creates contacts in Active Directory which Outlook can use as LDAP address book. Continue reading for the details.

The other day when using the Microsoft Online Transporter to migrate Exchange mailboxes to Microsoft Exchange Online, the following error was being returned on several of the mailboxes:

(401) Unauthorized

Typically when you see an error like that, you assume it's a permissions issue. In this case, the strange thing was that the mailbox migration had actually begun copying data to the Microsoft Exchange Online Mailbox and failed in the middle of the migration. After reviewing the migration logs, there were numerous warnings about timeout issues. To get around the issues, we simply reduced the number of simultaneous migrations, and reran the migrations. In other cases we just reran the migration and/or waited until off hours to retry the migration.

We recently ran into some clients that were displaying the following error when trying to sign into the Sign In Client:

The client was unable to establish a secure connection with the server. Please try signing in again. If the problem persists, please contact your system administrator.

After some investigation, it turns out the problem was the client's clock was too far out of sync with the Microsoft Online servers. When this occurs you'll also see the following logged in the Sign In Client log:

10/26/2009 9:22:29 AM Exception SingleSignOn.ParseSSOException System.ServiceModel.Security.MessageSecurityException
10/26/2009 9:22:29 AM Exception SingleSignOn.ParseSSOException Fault code: Sender
10/26/2009 9:22:29 AM Info SingleSignOn.ParseSSOException Generic MessageSecurityException caught. FaultCode is Sender. Most likely cause is bad system clock
10/26/2009 9:22:29 AM Exception SingleSignOn.ParseSSOException An error occurred when verifying security for the message.
10/26/2009 9:22:29 AM Info SingleSignOn.ResetConnectionsToService Closing all open connections