Exchange ActiveSync and Windows Phone 7 phantom data issue
Some of you may have seen stories about higher than expected data usage for a very small percentage of Windows Phone 7 users being caused by an inefficiency between Windows Phone 7 client and Yahoo! Mail. You may have also seen that these stories mention that there is a separate Exchange ActiveSync (EAS) issue that is impacting a small percentage of users. Unfortunately, like a game of telephone, many of the stories I've seen are combining these two issues into one, or mentioning both of these issues as if they have equal impact on users. For the record, Yahoo! Mail is not connected to Windows Phone 7 using EAS , and the Windows Phone 7 EAS implementation issue is much smaller. In some of the most egregious cases, some have called this a protocol level bug in EAS . This is untrue — this is a client issue. We on the Exchange team know that you all work very hard to make sure your Exchange servers are running well, so we wanted to get you some good information (straight from us here at Microsoft) about these issues. First off; for administrators, there's no need for any changes to your Exchange servers — the issues here are client-side and thus do not impact your servers nor increase the load on your servers. That said, we know that many of you work closely with your users and always try to help them out with good support information. If you have users who are contacting you about this issue or may be impacted, there are mitigations available for each of these issues while the Windows Phone 7 team continues to work with Yahoo! on a full software fix that is expected in the near term. For Windows Phone 7 EAS issue, users might see increased data usage when a message is "stuck" in their outbox. A user might encounter this state if they send email to an invalid email address or if they send a message that's larger than the allowed message size (server side policy) from their phone. In these cases, users can go to their Outbox folder and delete the stuck message and the phone's data use will return to normal. Below are the steps a user can take to see if there is a message stuck in their outbox and how to delete it. Note: This impacts only a very small percentage of Windows Phone 7 users and does not impact EAS users on other phone platforms. Click the folder icon at the bottom of the EAS -enabled inbox Select the Show all folders option Select the folder called Outbox (if you have a lot of folders, you may have to scroll down to see this folder) Delete any messages in this folder The Yahoo! Mail issue is not connected to EAS, but users can lessen the impact by changing the frequency that the Yahoo! Mail account is checked for new messages. Below are the steps to make this change: On the Start screen of Windows Phone 7, click on the arrow at the top right Choose Settings from the app list Choose email & accounts Choose Yahoo! Mail Click on the setting under Download new content Select a less frequent setting. If you are using the default setting (every 2 hours), change this setting to manually Click on the setting under Download email from Select a shorter time range. If you are using the default setting (the last 2 weeks), change this setting to the last 7 days Adam Glick Sr Technical Product Manager - ExchangeFun with changing E-Mail Addresses
One may think that making changes to the e-mail address of a mailbox is a simple thing, but Exchange does a bit of work to ensure the changes are correct and will not cause problems in the system. Here's an overview of how the UI updates e-mail addresses and how it validates and checks for uniqueness when changes are made. E-Mail Address Attributes Exchange stores and uses information about the e-mail addresses of a recipient in the following attributes: proxyAddresses This is the main attribute where e-mail address information is kept. When you open the properties of a recipient in Outlook and look at the "E-mail Addresses" tab, you are looking at this attribute. This is a multi-valued string containing all the addresses that represent the recipient. Each value must have the following format: type:address For example: SMTP:nospam@online.microsoft.com When the type is in uppercase letters, the address is considered to be the primary address of that type and it is used as the default reply address of that recipient. When the type is in lowercase letters, the address is considered a secondary address and is used to resolve addresses during e-mail delivery, allowing the same recipient to receive e-mails directed to different e-mail addresses. For example: Primary: SMTP:currentAlias@domain.com Secondary: smtp:oldAlias@domain.com On the 'Users and Computers' snap-in, this property is edited on the 'E-mail Addresses' page of a recipient. targetAddress In contacts and mail-enabled users this attribute contains the type and address of the mailbox represented by the recipient. This will point to a mailbox outside the Exchange organization, for example, to a hotmail account or to another's company address. On the 'Users and Computers' snap-in, this property is edited on the 'Exchange General' page of contacts and mail-enabled users. mail The value of this attribute corresponds to the primary SMTP proxy address. Windows often displays this attribute as the e-mail address of the user. On the 'Users and Computers' snap-in, this property is edited on the 'General' page of recipients. textEncodedOrAddress The value of this attribute corresponds to the primary X400 proxy address. On the 'Users and Computers' snap-in, this property is edited by changing the primary X400 address on the 'E-mail Addresses' page of recipients. It is important to note that the values found in mail, textEncodedOrAddress and targetAddress must also be included in proxyAddresses with their respective types, otherwise they would not be picked up when Exchange makes searches against proxyAddresses. However, this creates a problem: we actually need to keep these attributes synchronized to each other when the administrator makes changes to them, either in the UI or with CDOEXM. The problem is aggravated because in 'Users and Computers' Windows implements the property page that sets the mail attribute, while the Exchange extension implements the property pages with targetAddress and proxyAddresses. Not only do we need to synchronize changes when the property page is saved but we need to synchronize when the administrator flips from one page to the other, to keep the UI consistent. To do that, we run what we call the proxy-sync mechanism. Proxy-Sync Scenarios Proxy-Sync runs when an administrator makes a change in one of the e-mail attributes of a recipient and that change needs to be synchronized to another attribute. For example, when mail changes, the primary SMTP entry in proxyAddresses must also be updated so that both addresses are synchronized, but if you try to delete the mail attribute without mail-disabling the recipient, then we copy the primary SMTP address back to mail. The following list summarizes the changes supported by proxy-sync since Exchange 2000 SP2: 1. Action: Remove e-mail from General page. Results: Primary SMTP from proxyAddresses is copied back to mail. 2. Action: Modify e-mail on General page. Results: There are four cases to be considered: o If the new address already exists in proxyAddresses and: · it is the primary SMTP address: proxy is in sync already. · it is a secondary SMTP address: demote the curr ent primary SMTP and promote the new address to primary SMTP. o If the new address does not already exists in proxyAddresses and: · targetAddress is the primary SMTP: demote the current primary SMTP and add the new address as primary SMTP. · targetAddress is a secondary SMTP: replace the primary SMTP with the new address. 3. Action: Modify the primary SMTP on E-mail Addresses page, either by editing or by promoting a secondary address to primary. Results: new primary SMTP is copied to mail. 4. Action: Modify the primary X400 on E-mail Addresses page, either by editing or by promoting a secondary address to primary. Results: new primary X400 is copied to textEncodedOrAddress. 5. Action: Modify the address corresponding to targetAddress in the E-mail Addresses page. Results: The new address is copied to targetAddress. Actions 3 and 4 also apply if the edited address is a primary proxy. 6. Action: Modify the targetAddress in the Exchange General page of contacts and mail-enabled users. Results: The following rules are applied: o If the old targetAddress is the primary SMTP and the new targetAddress: · is also SMTP: remove the old primary SMTP. · is not SMTP: keep the primary SMTP intact. · In either case, continue following the next rules: o If there is already a primary address for the same type, add the targetAddress as a secondary address. o If there is not a primary address for the same type, add the targetAddress as a primary address and if it is SMTP or X400, copy to mail or textEncodedOrAddress, respectively. E-mail Address Validation Well, now that all our e-mail addresses are synchronized, we can try to save them, right? No, we are not quite there yet. Before saving we must make sure that all addresses are valid, according to their type. When validating the proxyAddresses attribute, we'll check the following: o There must be a primary SMTP address o There can be only one primary address of each type o Every secondary address type must have a corresponding primary address o All addresses must pass validation of their type · This is actually done by the proxy generation DLL associated with each type. I won't go in details on that here since you can find more information about them in MSDN. · Now, these DLLs will not be installed in an admin-only installation, so we need to RPC to an Exchange server and let the server perform that validation. The Exchange System Attendant service responds by calling each proxy DLL and letting them validate the e-mail addresses typed by the user. Can we save now? Close, but not yet. There is still one step left. Uniqueness Check We would not like to let an administrator accidentally create duplicate e-mail address when we can prevent that from happening. I mean, if that happens messages would start returning, people will complain and everybody gets frustrated. So let's do this one last thing before saving changes to the e-mail addresses of a recipient: let's make sure they are all unique in the organization. To do that, we perform an LDAP query against the Global Catalog, looking for any object that has any of the proposed values in its proxyAddresses attribute. The query will look somewhat like this, with as many clauses as e-mail addresses we need to check: (| (proxyAddresses=SMTP:alias@domain.com) (proxyAddresses=smtp:alias2@domain.com) ) Of course, we need to properly format and escape the e-mail addresses in the query but most importantly, we need to be aware of the fact that there may be one object with the same addresses that we're trying to save, which would be the object we are editing. That one is ok, but if anyone else shows up in that query, we have a duplicate and we do not allow the changes to be persisted. What about Recipient Policies? You may be wondering why I haven't mentioned Recipient Policies anywhere. The process described above happens in the user interface, completely independent of Recipient Policies. It goes without saying that once the recipient is updated, Recipient Policies will go make sure everything is according to policy, but that's another story. - Fabio PintosBasic Authentication and Exchange Online – July Update
Today we are pleased to announce some new changes to Modern Authentication controls in the Microsoft 365 Admin Center, exposing simpler options for customers to manage both Modern and Basic Authentication requirements within their organizations.
