Blog Post

Exchange Team Blog
2 MIN READ

Introducing the Exchange Web Services Managed API 1.0 Beta

The_Exchange_Team's avatar
Apr 21, 2009

If you haven't heard the buzz yet about what is new with our Exchange 2010 developer story then head over to the Exchange Developer Center and start digging in to the Exchange Web Services Managed API Beta and our other new features. Download the first fully managed API from the Exchange team that enables easy access to mailbox data leveraging the powerful Exchange Web Services. This API opens up the world of Exchange development like never before. Retrieving all of the calendar items on my calendar for this week is as simple as:

//Instantiate the service ExchangeService testService = new ExchangeService(); //AutoDiscover the correct EWS endpoint for this user to use testService.AutodiscoverUrl("testuser@contoso.com"); //Bind to the logged on user's calendar folder CalendarFolder myCalendar = CalendarFolder.Bind(testService,WellKnownFolderName.Calendar); //Query for items for the upcoming week - Expanding all recurrences //using CalendarView FindItemsResults<Appointment> myAppointments = myCalendar.FindAppointments(new CalendarView(DateTime.Now,DateTime.Now.AddDays(7))); //Write out the subject of each appointment I have this week foreach(Appointment appointment in myAppointments) Console.WriteLine(appointment.Subject);
And great news for Exchange 2007 application developers the EWS Managed API Beta will work with Exchange 2007 SP1 servers as well as Exchange 2010 servers. Of course you'll need to upgrade to Exchange 2010 to get access to new Exchange 2010 specific web services features like contact Group creation, associated item access, user configuration object access, conference room retrievals, and expanded unified messaging functionality. We've also added features for the IT Administrators out there that help protect your servers from resource hungry applications. Client Access throttling enables administrators to regulate the amount of resources available to a user or account accessing the Client Access Server through OWA, EWS, EAS, PowerShell and other protocols. One of our very popular features from Exchange 2007, Exchange Web Services Application Impersonation, is now much simpler to deploy and administrate with an RBAC role. Remember to check out the Exchange Developer Forums, Exchange Developer Center, and Exchange Developer Blog for more details. - Jason Henderson
Updated Jul 01, 2019
Version 2.0
  • And, as with any .NET library, the API can be accessed from PowerShell. Wee-ha!



    $dllpath = “C:Program FilesMicrosoftExchangeWeb Services1.0Microsoft.Exchange.WebServices.dll”


    [void][Reflection.Assembly]::LoadFile($dllpath)

    $service = new-object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2007_SP1)


    $uri=[system.URI] ”

    https://YOUR.EWS.FQDN/ews/exchange.asmx”

    $service.Url = $uri

    $inbox= [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,[Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox)


    $perms = $inbox.permissions

    # and so on, and so forth....

  • Really cool, can't wait to dig into this!
  • I have started looking into the new API and I must say the APIs are super easy to work against.
     I have a following situation:

    1. Using AddDelegate method I have given"superuser" as Editor permission on calendar folder of 2 users: user1, user2.

    2. Now using superuser's credentials I want to be able to create calendar items in those user's calendar folder. Appointment constructor takes ExchangeService object as a parameter, however, it will take only superuser's credentials to connect.

    Kindly let me know your feedback.

    Thanks,
    Furqan
  • It does look neat, but what would be the performance impact against using something like MAPI?

    Jason