The Curious Case of the Persistent EmailAddress1


There's a rather puzzling issue that many developers creating their own jazzy EWS customizations tend to encounter, when they try modifying the Email Address associated with a contact item.

The issue is that when they try using an EWS call to do away with any of the Email Addresses associated with the contact item through EWS calls by setting to an empty string (i.e. ""), and then persist the change through an Update() call, they think that their work is done. Fire up Outlook or log into your OWA, navigate to that Contact in your Address Book, and lo-behold, they find the erstwhile email entry is sitting right there, as if it had never budged to begin with.

 

The underlying issue here is that the EWS call, against everybody's expectations, clears out one property associated with the Email Address field, called Email1EmailAddress (Documentation Here). At the other end of the rainbow, Outlook and OWA, while figuring out the Email Address for the contact item, rely on 2 other properties, christened Email1DisplayName (Documentation) and Email1OriginalDisplayName (Documentation)

So the question that remains is... What do we do?

Well, it's rather obvious, isn't it? (Okay, maybe not.) We remove the truant properties themselves! The easiest (and probably only) way to do that through EWS is by accessing them via ExtendedProperties.

Here's a code snippet I chalked out to do that for you...

static void RemoveTheEmailAddressPlease(ExchangeService service)
       {

           // To begin with, we create definitions for the Extended Properties that we'll be exterminating

           ExtendedPropertyDefinition EmailAdd = new ExtendedPropertyDefinition(DefaultExtendedPropertySet.Address, 32899, MapiPropertyType.String); //Corresponds to Email1EmailAddress 

           ExtendedPropertyDefinition DispName = new ExtendedPropertyDefinition(DefaultExtendedPropertySet.Address, 32896, MapiPropertyType.String); //Corresponds to Email1DisplayName 

           ExtendedPropertyDefinition OriginalDispName = new ExtendedPropertyDefinition(DefaultExtendedPropertySet.Address, 32900, MapiPropertyType.String); //Corresponds to Email1OriginalDisplayName


           // Then, it's time to retrieve Contact Items for us to perform the exterminationon

           ItemView view = new ItemView(10);

           view.PropertySet = new PropertySet(BasePropertySet.IdOnly, DispName, EmailAdd, OriginalDispName); //Here, we specify our intent of retrieving the values for those 3 Extended Props 

           view.Traversal = ItemTraversal.Shallow; //Assuming your contact item isn't present within a sub-folder



           String searchstring = "AAMkADBkODh"; // Very Arbitrary ItemID... Please use Logic to determine your own! 
           SearchFilter.IsEqualTo filter = new SearchFilter.IsEqualTo(ContactSchema.Id, searchstring);

           // Search your Address Book and get the result! 
           FindItemsResults<Item> findResults = service.FindItems(WellKnownFolderName.Contacts, filter, view);

           // And alas, remove the Email Address 
           if (findResults.Items.Count > 0)
           {

               foreach (Item myItem in findResults.Items)
               {

                   if (myItem is Contact)
                   {

                       if (myItem.ExtendedProperties.Count > 0)
                       {
                           myItem.RemoveExtendedProperty(DispName);
                           myItem.RemoveExtendedProperty(EmailAdd);
                           myItem.RemoveExtendedProperty(OriginalDispName);

                           myItem.Update(ConflictResolutionMode.AlwaysOverwrite);

                       }

                   }

               }

           }
           else
           {

               Console.WriteLine("Ermm... No Contact Item Found!");

           }

       }

And lo behold, it's done! (I hope!)


Comments (1)
  1. WernerCD says:

    Hours searching, and this got me almost there. I also had to delete "OriginalEntryID" and "EmailType". Not sure if it's because of 2013 version or not, but still. Cudo's

Comments are closed.

Skip to main content