Search results matching tag 'devmsgteam'

Microsoft Office 2010 beta is available to download

brijs — Thu, 19 Nov 2009 08:00:00 GMT

I am very excited to share that Microsoft announced the public beta release of Office 2010, SharePoint Server 2010, Visio 2010, Project 2010, Office Web Apps for business customers, and Office Mobile 2010.

If you are developing application based on Outlook; then here are few links related to developing applications for Outlook 2010:

If you are looking for resources to learn more about Office 2010. Then the Office 2010 Developer Workshop includes videos and presentations @ Office 2010 Workshop. This content is designed to help you get started developing solutions, from Add-ins to full featured Office Business Applications (OBAs), using Visual Studio 2010 with Office 2010 and SharePoint 2010 as the core platform.

So, what are you waiting for? hit the road with Office 2010 Developer Roadmap.

And to complement it we can download Microsoft Visual Studio 2010 Professional Beta and refer to

Visual Studio 2010 - What's New in Office Development as well.

Enjoy Learning!!!

Exchange Server 2007 SP2 Update Rollup1 is available to download

brijs — Thu, 19 Nov 2009 08:00:00 GMT

Exchange Server 2007 SP2 Update Rollup 1 is available to download @ Download the Exchange2007-KB971534-EN package now.

Update Rollup 1 for Exchange Server 2007 Service Pack 2 (SP2) resolves issues that were found in Exchange Server 2007 SP2 since the software was released. This update rollup is highly recommended for all Exchange Server 2007 SP2 customers. For the details related to the issue fixed by it refer to Description of Update Rollup 1 for Exchange Server 2007 Service Pack 2.

If you are developing application based on Exchange Web Services then following are the issues fixed by Update Rollup 1 for Exchange Server 2007 Service Pack 2 (SP2):

973868 A delegate cannot cancel meetings in the organizer's calendar by using Exchange Web Service (EWS)
973307 An application that uses Exchange Web Services returns an exception on an Exchange Server 2007 server
972009 E-mail messages cannot be retrieved by an Exchange Web Service (EWS)-based application if there are invalid control characters in the text body of the e-mail message

So, if you are on Exchange Server 2007 SP2; I would highly recommend you to download and install Update Rollup 1 to fix the know issued with Exchange Server 2007 SP2.

November 2009 Release of MFCMAPI

Stephen Griffin — Tue, 17 Nov 2009 08:00:00 GMT

The November 2009 Release (build 6.0.0.1016) is live: http://mfcmapi.codeplex.com.

The September 2009 release was downloaded over 18 thousand times, with nearly 1700 of them being the 64 bit build. This exceeded the July build by about 4000 downloads. Yay MFCMAPI!

Mostly bug fixes this time around. Win 7 finally made me dig into why Close All Windows wasn’t working, and I did a bit of work to make MFCMAPI a better multimon client.

Here's a change list - see the Issue Tracker on Codeplex for more details, or look at the code:

Close All: Shutdown of contents table windows was swallowing the WM_CLOSE message for the other windows. Whoops!
Multimon: New windows and context menus now show on the same screen as their parent window, as they should.
Unicode Files: MFCMAPI can now handle files (like .msg or .eml files) that have Unicode characters in their names.
Property Editor: It’s now possible to manually insert CR/LF characters directly in the hex stream of a property and write the exact data you intended, as long as you don’t touch the text editor. This is to work around a bug/feature of the rich edit control that made reproducing certain issues impossible.
Smart View: Can now turn Smart View off if you’ve got a property that’s causing it to choke. Do continue to report these to me though!
Version selection: Did some work to make it clearer when you’re running the wrong version of MFCMAPI (32/64) for the version of MAPI you have.
Error Dialog Suppression: Identified a number of “error” dialogs that confused more than they helped and eliminated them. If there was an actual error it’s written to the debug output.
Tons of minor issues – 22 total bugs tied to this release, and those are just the ones that were worth calling out.

Enjoy.

Where CDO Publishes Free Busy Information

Stephen Griffin — Mon, 16 Nov 2009 08:00:00 GMT

From time to time, I get asked to explain where CDO publishes Free Busy information in the Public Folder store, so I figured I’d put this article together. The basic process CDO uses for updating FB information is outlined in the More Information section of KB 278954. We’re concerned with the part of the process summarized as “queued up to be sent to the site’s Free/Busy public folder.”

The first thing CDO does is to open the Public Folder store and read a couple properties off of it, PR_FREE_BUSY_FOR_LOCAL_SITE_ENTRYID (0x66250102) and PR_SPLUS_FREE_BUSY_ENTRYID (0x66220102). These entry IDs will point at a couple folders in the Public Folder store. The first entry ID points the Free Busy folder for the user’s site, the folder CDO wants to look in for the Free Busy message. If CDO cannot open the folder specified by PR_FREE_BUSY_FOR_LOCAL_SITE_ENTRYID, it turns to the second property, PR_SPLUS_FREE_BUSY_ENTRYID, which points at the “SCHEDULE+ FREE BUSY” folder, a child folder of the NON_IPM_SUBTREE folder. This property will point at the same folder for all users. In this case, CDO will use an algorithm similar to the one described in [MS-OXOPFFB] to find the correct site folder for the Free Busy message.

The point of failure here is the Entry ID specified in PR_FREE_BUSY_FOR_LOCAL_SITE_ENTRYID. If this points at the wrong folder, CDO will publish Free Busy information to the wrong folder, and other clients won’t see the updated Free Busy. This property is not one that anybody sets. It’s actually computed on the server side. No amount of changes to a CDO based program can get it to publish Free Busy to the correct folder if the server is handing out the wrong site folder.

This is where server side troubleshooing articles such as KB 326637 and Exchange Public Folder Troubleshooting Resources come in handy. They walk you through the various things that could be wrong with site folders and how to fix them. If PR_FREE_BUSY_FOR_LOCAL_SITE_ENTRYID is pointing at the wrong folder for your users you’ll need to use the steps in those articles to locate the problem and fix it.

Suppose you just want to determine if PR_FREE_BUSY_FOR_LOCAL_SITE_ENTRYID is pointing at the folder you’d expect it to point to for a particular user. You can use MFCMAPI to see where this entry ID points to.

First, we check which folders we’re being pointed at:

Open MFCMAPI on the machine where your CDO application runs.
Log on to a profile. You’ll get your best results if you can use the same profile the CDO application uses.
Select the Public Folder store in the list of stores.
The properties we want may or may not show in the default list of properties, so we’ll add them:

Click Property Pane/Modify Extra Properties
Click Add
In the Property Tag field, type in PR_FREE_BUSY_FOR_LOCAL_SITE_ENTRYID. The rest of the form should fill out automatically.
Click OK, then click Add again.
In the Property Tag field, type in PR_SPLUS_FREE_BUSY_ENTRYID. The rest of the form should fill out automatically.
Click OK, then click OK again to close the Extra Properties window.

We’ve added the properties, so they should show in the property pane. You can sort by the Property Name column and look them up by name, or sort by the Tag column and look them up by number (0x66250102 for PR_FREE_BUSY_FOR_LOCAL_SITE_ENTRYID and 0x66220102 for PR_SPLUS_FREE_BUSY_ENTRYID.
Right click on PR_FREE_BUSY_FOR_LOCAL_SITE_ENTRYID and select Open as Entry ID or Object. In the dialog that comes up, hit OK.
In the resulting hierarchy view, you can now read the name of the site folder the server has directed you to.
Switch back to the main window and reselect the Public Folder store to refresh the property list.
Right click on PR_SPLUS_FREE_BUSY_ENTRYID and select Open as Entry ID or Object. In the dialog that comes up, hit OK.
This will display the hierarchy for the SCHEDULE+ FREE BUSY folder. Click the + icon to display the list of all the site folders in the Public Folder store.

Next, we determine which folders we should be looking at, following the algorithm from [MS-OXOPFFB]:

In the main window of MFCMAPI, select Session/Display Current User Properties. Hit OK.
In the Property Pane, locate PR_SEARCH_KEY (0x300B0102).
Double-click on the property to open it, and take note of the Text field. For me, this says “EX:/O=MICROSOFT/OU=NORTHAMERICA/CN=RECIPIENTS/CN=420275”
The appropriate site folder can be derived by truncating this string at the / before the first CN. So for me, my site folder should be “EX:/O=MICROSOFT/OU=NORTHAMERICA”.

So, now you know what site folder the user has listed in PR_FREE_BUSY_FOR_LOCAL_SITE_ENTRYID, and you know the name of the site folder they should be using. If these two are not the same folder, then you have site folder issues and need to get them addressed.

Hopefully, this should be enough to help folks who are having site folder issues to understand that CDO is just the innocent victim here when it publishes Free Busy to the wrong folder, and that server side configuration is the real villain.

Enjoy!

Issue accessing Public Folder Store using CDO 1.2.1 for Outlook 2007

brijs — Fri, 13 Nov 2009 08:00:00 GMT

If you are using InfoStores collection of CDO 1.2.1 for Outlook 2007 to access Public Folder store and not able to get reference to Public Folder store then here is the explanation of the design change in CDO 1.2.1 from SGriffin’s post@Outlook 2007, Public Folders, MAPI and You.

Basically, Outlook 2007's version of the Exchange provider, emsmdb32, doesn't automatically add the Public Folder store to the message store table of a new profile. Instead, it waits until a successful connection has been made to the Exchange server. If it then detects that the public folders are available, it updates the profile and sends a table notification indicating the availability of Public Folders. This is a change from previous versions of Outlook and from Exchange's version of the provider. We made this change to better support Exchange 2007's Public Folder-less environments.

Here is the vbscript sample code snippet to repro the issue:

NOTE: Following programming examples is for illustration only, without warranty either expressed or implied, including, but not limited to, the implied warranties of merchantability and/or fitness for a particular purpose. This sample code assumes that you are familiar with the programming language being demonstrated and the tools used to create and debug procedures. This sample code is provided for the purpose of illustration only and is not intended to be used in a production environment.

'Change Server and User name below

SERVER = "Server"

Mailbox = "User"

Set objSession = CreateObject("MAPI.Session")

objSession.LogOn , "", False, True, , True, SERVER  & Chr(10) & Mailbox

    Set objInfoStores = objSession.InfoStores

     For i = 1 To objInfoStores.Count

        If UCase(objInfoStores.Item(i)) = UCase("Public Folders") Then

            Set objInfoStore = objInfoStores.Item(i)

                msgbox objInfoStore.name

            Exit For

        End If

    Next

Set objInfoStores= Nothing

Set objSession=Nothing

The above sample code would not return the name of the Public Folders store to us.

We need to work around the above issue by creating another session object as per the below code snippet:

'Change Server and User name below

SERVER = "Server"

Mailbox = "User"

Set objSession = CreateObject("MAPI.Session")

objSession.LogOn , "", False, True, , True, SERVER  & Chr(10) & Mailbox

    Set objInfoStores = objSession.InfoStores

     For i = 1 To objInfoStores.Count

        If UCase(objInfoStores.Item(i)) = UCase("Public Folders") Then

            Set objInfoStore = objInfoStores.Item(i)

                msgbox objInfoStore.name

            Exit For

        End If

    Next

Set objSession2 = CreateObject("MAPI.Session")

objSession2.LogOn , "", False, False, , True, SERVER  & Chr(10) & Mailbox

    Set objInfoStores2 = objSession2.InfoStores

     For i = 1 To objInfoStores2.Count

        If UCase(objInfoStores2.Item(i)) = UCase("Public Folders") Then

            Set objInfoStore2 = objInfoStores2.Item(i)

                msgbox objInfoStore2.name

            Exit For

        End If

    Next

Set objInfoStores= Nothing

Set objSession=Nothing

Set objInfoStores2= Nothing

Set objSession2=Nothing

Note: We are using third parameter as “False” for objSession2.Logon, So that it uses the current shared MAPI session.

Exchange Web Services Managed API and EWS Editor is available!

brijs — Fri, 13 Nov 2009 08:00:00 GMT

If you are developing using Exchange Web Services Managed API then now you can download @ Microsoft Exchange Web Services (EWS) Managed API 1.0

The Microsoft Exchange Web Services (EWS) Managed API 1.0 provides a managed interface for developing client applications that use Exchange Web Services. The EWS Managed API simplifies the implementation of applications that communicate with Microsoft Exchange Server 2007 Service Pack 1 (SP1) and later versions of Microsoft Exchange. Built on the Exchange Web Services SOAP protocol and Autodiscover, the EWS Managed API provides a .NET interface to EWS that is easy to learn, use, and maintain.

Moreover, If you are looking for sample application developed using Exchange Web Service Managed API then EWS Editor is a great resource to have. Read more details about EWSEditor and download it from Matt’s post @ Announcing EWSEditor 1.5! Here are the few points which I really liked about it:

1. Demonstrate the Exchange Web Services Managed API functionality and simplicity to developers through its source code.
2. Demonstrate the Exchange Web Services SOAP traffic used to perform actions initiated through an explorer user interface.
3. Assist non-developers in debugging and understanding Exchange stores by exploring items, folders, and their properties in depth. “

EWS rocks!

Strange Looking NDR

Stephen Griffin — Thu, 12 Nov 2009 08:00:00 GMT

Not many people are aware of the feature, but MFCMAPI implements a MAPI Form Viewer. This means MFCMAPI can use MAPI to ask Outlook to display messages. You might have run into this if you ever double-click on a message in MFCMAPI. If you’re on a machine with Outlook installed, the message will open up like it does when you double-click it in Outlook. And if Outlook isn’t installed and you’re using Exchange’s MAPI, you get a scary dialog saying we couldn’t open the MAPI form manager.

This is one of those dark corners of MAPI into which few people tread, and most of those who do end up cribbing or parroting the Form Viewer implementation in MFCMAPI itself, meaning nearly every issue they report related to form viewers can be reproduced in MFCMAPI. Sometimes, this turns out to be a bug in my implementation, like an errant warning while clicking up and down through messages (fix coming very soon!). Other times, the problem is a bug in Outlook.

My latest customer’s issue turned out to be the latter case. They had noticed that when they tried to view NDR messages with their Form Viewer, the body of the message would be full of alien looking RTF text:

“{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fmodern\fcharset0 Consolas;}}
{\*\generator Riched20 12.0.6413.1000;}\viewkind4\uc1
\pard\fi-1440\li1440\tx1440\f0\fs21 Your message did not reach some or all of the intended recipients.\par
etc…”

What was really odd was that if you looked at the message in MFCMAPI, this text was no where to be found! And to top it off – if you opened the message from Outlook, you got the NDR message you expected.

So what was going on? It’s not surprising that Outlook builds the NDR text on the fly. It’s much easier to localize it that way. And the RTF does appear to be the underlying RTF we would generate for the NDR message. But why did we display it wrong, and why did Outlook display it right?

The key here is the LoadForm function. This function takes the message class of the form we want to load. Under the covers, LoadForm looks up the message class using ResolveMessageClass and gets the GUID for the associated class factory. The form manager then passes this GUID over to Outlook and asks for the class factory. This is where we have a problem. Outlook uses the same GUID for multiple form class factories, some of which have different attributes associated with them. The class factory we get has an attribute on it stating it should render using HTML, while the class factory we should have gotten did not have this attribute. So when it comes time to render the text, we use the wrong rendering method and get the ugly RTF text.

When Outlook opens the message, being the implementer of the forms, it gets to skip many of the MAPI steps. Instead of using the message class to look up a GUID, it uses the message class to look up the class factory directly, getting the right one in the process.

Based on the fact that this behavior has been unchanged for as long as we can trace back, and we’re only just now hearing of an issue with it, we chose not to fix this problem, but instead document it. So – here’s the documentation. Enjoy!

How to do FindItem using Extended MAPI Properties in a Exchange Web Service call?

brijs — Thu, 12 Nov 2009 08:00:00 GMT

We can perform GetItem Exchange Web Service call to get Extended MAPI Properties refer my previous post How to get Extended MAPI Properties in the GetItem Exchange Web Service call? and can also perform FindItem based on the Extended MAPI Properties.

In the sample code given below we would use CleanGlobalObjectId to perform FindItem for Calendar Items:

    private void SelectRecordByCGOID()

            //prepare the find item request: we have to use FindItem because

            //this is the only way to search by CleanGlobalObjectID; GetItem does not allow us

            //to search with Restrictions

            FindItemType findItemRequest = new FindItemType();

            DistinguishedFolderIdType[] folderIDArray = new DistinguishedFolderIdType[1];

            folderIDArray[0] = new DistinguishedFolderIdType();

            folderIDArray[0].Id = DistinguishedFolderIdNameType.calendar;

            folderIDArray[0].Mailbox = new EmailAddressType();

            folderIDArray[0].Mailbox.EmailAddress = "brijs@msglab.com";

            // Add folders to the request.

            findItemRequest.ParentFolderIds = folderIDArray;

            findItemRequest.Traversal = ItemQueryTraversalType.Shallow;

            //Prepare an Item shape type that defines how the items in view will be returned.

            ItemResponseShapeType itemShapeDefinition = new ItemResponseShapeType();

            itemShapeDefinition.BaseShape = DefaultShapeNamesType.AllProperties  ;

            //filter the results by the CleanGlobalObjectID passed in

            PathToExtendedFieldType path = new PathToExtendedFieldType();

            path.PropertyId = 35;

            path.PropertyIdSpecified = true;

            path.PropertySetId = "6ED8DA90-450B-101B-98DA-00AA003F1305";

            path.PropertyType = MapiPropertyTypeType.Binary;

            FieldURIOrConstantType constant = new FieldURIOrConstantType();

            ConstantValueType constantValue = new ConstantValueType();

            constantValue.Value = itemGCOID ;

            constant.Item = constantValue;

            RestrictionType restriction = new RestrictionType();

            IsEqualToType equal = new IsEqualToType();

            equal.Item = path;

            equal.FieldURIOrConstant = constant;

            restriction.Item = equal;

            //Add the itemShape definition and restriction to the FindItem request

            findItemRequest.ItemShape = itemShapeDefinition;

            findItemRequest.Restriction = restriction;

            FindItemResponseType findItemResponse = binding.FindItem(findItemRequest);

            for (int i = 0; i < findItemResponse.ResponseMessages.Items.Length; i++)

                //verify the FindItem request was successfull

                if (findItemResponse.ResponseMessages.Items[i].ResponseClass != ResponseClassType.Success)

                    throw new Exception(string.Format(

                        "Unable to find calendar view by CleanGlobalObjectID \r\n{0}\r\n{1}",

                        findItemResponse.ResponseMessages.Items[i].ResponseCode,

                        findItemResponse.ResponseMessages.Items[i].MessageText));

                else

                        //Success

                        //get the calendar items contained in the response

                        FindItemResponseMessageType findItemResponseMessage = (FindItemResponseMessageType)findItemResponse.ResponseMessages.Items[i];

                        ArrayOfRealItemsType findItemResponseItems = (ArrayOfRealItemsType)findItemResponseMessage.RootFolder.Item;

                        for (int x = 0; x < findItemResponseMessage.RootFolder.TotalItemsInView; x++)

                            if (findItemResponseItems.Items[x] is CalendarItemType)

                                CalendarItemType calendar = (CalendarItemType)findItemResponseItems.Items[x];

                                Console.WriteLine( "Item found ");

                                Console.WriteLine( calendar.Subject);

Hope this helps!

EWS has "More Happy" now - EWS Managed API and EWSEditor.

danba — Tue, 10 Nov 2009 08:00:00 GMT

Want to make working with Exchange Web Services (EWS) much easier to work with? There is a new API and new tool which can help. No matter which way you are doing or going to be doing EWS calls, you should be familiar with both the Exchange Web Services Managed API and EWSEditor.

Exchange Web Services Managed API:

The Exchange Web Services Managed API makes life much easier since it wraps a lot of calling code and logic which is needed to successfully execute EWS calls. No matter how you are doing EWS calls (pure soap calls, using generated .Net proxies or a third party API that does EWS calls), you should become familiar with this new API which released on Monday with Exchange 2010. This API will work with both Exchange 2010 and 2007. This API is a lot easier to use than other coding methods and can reduce code to well under 30% of what’s needed with generated proxy code (my observation). Compared to WebDAV, you would need to write as little as 1.5% of the code with the EWS Managed API - an example of this is sending a meeting request. Yes, that 1.5% is correct. As you can see, this new API is indeed the "go-forward" API for working with mailbox content.

EWSEditor:

There is a tool called EWSEditor which is written by a member of my team and used by our entire support team. It’s based-upon the EWS Managed API and is helpful in showing how calls using this API can be used since you can get the source code. We have been using it since Matt started building his tool using the early Beta of the Managed API in order help diagnose issues on customer’s systems. Having source code samples when learning a new API is often invaluable, so be sure to get a copy of the source for EWSEditor to use as a reference. Please check-out Matt’s blog below for more information on his tool and source code.

Announcing EWSEditor 1.5!

http://code.msdn.microsoft.com/ewseditor

ExchangeWebServices Namespace (generated .NET proxies)

http://msdn.microsoft.com/en-us/library/exchangewebservices.aspx

Exchange Web Services Managed API

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=c3342fb3-fbcc-4127-becf-872c746840e1

Introducing the Exchange Web Services Managed API 1.0

http://msdn.microsoft.com/en-us/library/dd637749.aspx

Microsoft Exchange Web Services Managed API 1.0

http://msdn.microsoft.com/en-us/library/dd633709.aspx

One thing which I would strongly suggest is that if you find that your code does not work, try using EWSEditor to see if you can reproduce the issue. If the operation you are trying to perform is not covered with EWSEditor, then try to see if the problem reproduces with the EWS Managed API. EWSEditor & the EWS Managed API have the ability to log off EWS calls being performed. You can use this logging feature to compare what EWSEditor/The EWS Managed API sends with what your application sends in order to determine where a problem is with your code.

Big kudos for…

The Exchange Development Team for creating the EWS Exchange Managed API.

Matt for building EWSEditor and getting it public!!!

Announcing EWSEditor 1.5!

Stephen Griffin — Mon, 09 Nov 2009 08:00:00 GMT

Matt’s very excited about the release of EWSEditor. This tool does for EWS what MFCMAPI does for MAPI. With this tool, Matt does what I did with MFCMAPI and what I recommend to anyone trying to learn a new API: the best way to learn an API is to write tools that use it.

As you work with EWSEditor, you may notice a few things which are similar to MFCMAPI. This is no coincidence. EWS and MAPI, both designed primarily to interact with an Exchange server, share much of the same object hierarchy, which in turn dictates that tools designed to explore these hierarchies will be similar. Also, since we sit near each other and act as each other’s ad-hoc PMs, we borrow each other’s features. For instance, EWSEditor implements much of the same Smart View parsing as MFCMAPI, using the same logic, recoded from C++ to CSharp.

Of course, there’s one similarity between EWSEditor and MFCMAPI that has nothing to do with the underlying APIs or fancy features and everything to do with the fact that Matt and I are programmers, not icon designers. Look familiar?

Enjoy!