• Wiz/dumb

    What am I gonna do with 40 subscriptions to http://Vibe?

    • 1 Comments

    So this is a scenario you could easily find yourself in as one of my larger customers did recently. The answer is also one of the less-obvious, more obvious of answers. So imagine the scenario: you have load balanced Exchange FE (front end) boxes serving a myriad of back ends. Or, in a slightly less dramatic scenario, you have a stand-alone box with a few mailbox stores on it....In either case, or several in between, the problem may surface. You are writing an application that uses the WebDAV subscription/call-back notification capabilities of Exchange to monitor for updates to certain folders in certain mailboxes. Your application has a list of paths to subscribe to (http://email.domain.com/Exchange/mailbox1/Calendar, http://email.domain.com/Exchange/mailbox2/Calendar, etc). As it rolls through the subscription list, you notice that the subscription-id header you are returned appears to be a duplicate!

    Well this just won't do. How will your application be able to effectively know what folder issued the notification when the subscription-id now seems apparently ambiguous. The answer, my friend, is the OTHER header you are returned...subscribe-group. Subscribe-group is the base64-encoded GUID of your store. Subscriptions are managed per store which means if you have more than one store on a box, or more than one back end Exchange server, you have more than one subscription list being maintained. The only way to distinguish between them is to capture the subscribe-group header in addition to subscription-id. The NOTIFY on callback will provide you with both and so will the response to your SUBSCRIBE request, so you should be good to go. You will already implicitly know what store you are talking to when you POLL, so the subscribe-group does not need to be echoed to the server. Subscribe-group only helps the client application know which subscription it is receiving a call back for.

  • Wiz/dumb

    S/MIME Magic

    • 0 Comments

    I know it's been a while since I posted (for all my loyal fans!) but my wife and I had a baby last month, so we've been busy with him. Jacob Matthew is a great kid though, so I'm not apologizing, just giving you an explanation! On to business...

    So recently I had a case where the customer was using the Outlook Object Model to parse messages in his Inbox. That's a pretty normal thing do I thought. His problem that was on certain S/MIME (Secure MIME) messages, the Outlook Object Model bombed. Upon investigation it turned out that it was when he was accessing the Body property that the exception was thrown. So like any other Developer Support Engineer in the Messaging and Collaboration team, I cracked that message open with our favorite tool, MFCMapi, written by my colleague, the renowned Stephen Griffin. Not only is the guy a MAPI genious, he also seems to remember every TV show or movie he has ever seen and who was in it.

    Back to the story...

    So there I was knee-deep in MFCMAPI and I'm looking at this message. I have some other S/MIME messages in my mailbox so I can compare them. So as I'm looking at the PR_ props of my problem message and I notice that I don't see the PR_HTML property...in a flutter of panic, I look for the PR_BODY property...nothing. Well, that's ok, often times messages get stuffed into the PR_RTF_COMPRESSED property. And that would be fine and good, except that that property was missing also. DUN DUN DUUUUNNNN...

    So where is the message? I can see it in Outlook, but it doesn't appear to be in any properties in the MAPI message.

    Then it hit me...this message carries a copy of itself in a hidden attachment called smime.p7m. This helps ensure that the message content does not change since whoever signed the message originally originally signed the message. I opened up the attachment and sure enough, the content of the message was in a property called PR_ATTACHMENT_DATA_OBJ. Well that clears up one mystery. This doesn't necessarily explain why the Outlook Object Model throws an exception.

    Well, this story doesn't have a really happy ending. I'm not sure why the Body property fails...I know that it happens in source when the HTML stream is being copied into the Text stream, but that's all I know. What I do know is that the HTMLBody works. So if you find an exception gets thrown when you are trying to access the Body property on a message object, try hitting the HTMLBody property as a backup and strip out the HTML tags yourself using regular expressions or something like that.

  • Wiz/dumb

    CDO Workflow Designer Troubleshooting

    • 0 Comments

    If you've ever tried to start a CDO Workflow project using Office Workflow Designer and encountered the infamous Can Register Workflow error, you're not alone. I've seen users with that error a few times so far and their problem seems to be the same in each case. The most helpful hint is not the one you get from Office Workflow Designer, but the one in the Application event log on your Exchange server. Chances are, your event log will tell you that Enforce Access Restrictions are not enabled. If that's the case, You need to drill into your COM Configuration settings and click the properties on your CdoWfEvt.EventSink.1 and go to the Security Tab and click the checkbox to enforce component-level access restrictions.

    Here are some other helpful troubleshooting hints for Workflow problems:

    1. Verify that you can access and are an Owner of the Public Folder to which you are trying to publish the workflow. Verify that you can access the folder using OWA by navigating to http://<server>/public/<foldername> and that the public folder is "Homed" on that server. 
    2. Make sure you have the Can Register Workflow role and the Priviledged Workflow Author role explicitly.
    3. Verify that NT System\Authority also has Priviledged Workflow Author
    4. Make sure that Enforce Access Restrictions is turned on on both the Workflow Event Sink and CdoWfEvt.EventSink.1 items.
    5. Verify that your Workflow Event Sink component is set to use the identity of a domain user who
      1. Is a domain user
      2. Has a mailbox on the same server.
      3. Is in the Can Register Workflow and Priviledged Workflow Authors roles (explicitly)
      4. is in the Exchange Domain Servers AD group
    6. In Exchange System Manager, drill into the HTTP Protocol on your server and right click on Public to go to Properties. Make sure that Basic Authentication is Checked and that Scripts and Executables are enabled.

    Hopefully one of these troubleshooting steps can help you be able to create Workflow projects successfully! 

  • Wiz/dumb

    VSTO add-ins and the NewInspector Event

    • 28 Comments

    VSTO add-ins for Outlook are great. It's much easier than implementing the IDTExtensibility2 interface. Basically, the way it works is this (actually, Andrew Whitechapel does a much better job explaining than I will, so here you go): the AddinLoader.dll keeps a "dormant" list of add-ins that tried to load when the Outlook.exe process is started.

    If there's UI (if there are any Explorers or Inspectors visible), then it fires the _Startup event. If there is no UI (like when using the Outlook View Control or ActiveSync), then it doesn't fire _Startup until the first Inspector or Explorer is made visible. Once the last UI element is closed, then VSTO fires the _Shutdown event.

    A typical operation one would usually perform (and a reason for creating an add-in in the first place) is to add some sort of UI to an Inspector or Explorer, such as a button on a command bar or a menu item. In a traditional COM add-in, the way you would do this would be to hook in to the Inspectors.NewInspector event and in the handler for that event, you'd add your UI. And that works great. It works great in VSTO also, except the first time.

    Because VSTO itself is waiting until the NewInspector event fires (in scenarios where Outlook.exe is started with no UI) to fire the _Startup event on your VSTO add-in, it is too late to bind to the event yourself (it's already been fired). So what happens is that the first time an Inspector opens, your button is not added to the CommandBar, but the second time it is!

    The way to get around this problem is simple. Remember that the _Startup event is fired during the NewInspector event. So in your _Startup code, just check the Inspectors.Count property and if it's greater than 0, go ahead and add your button (or whatever)! In subsequent calls to the NewInspector, your code will fire.

    Here's an example:

    private Microsoft.Office.Interop.Outlook.Inspectors objInspectors;

    private void ThisApplication_Startup(object sender, System.EventArgs e)
    {
       objInspectors = this.Inspectors;
       objInspectors.NewInspector += new Microsoft.Office.Interop.Outlook.InspectorsEvents_NewInspectorEventHandler(objInspectors_NewInspector);
       if(objInspectors.Count >= 1)
          AddCustomUI();
    }

    private void ThisApplication_Shutdown(object sender, System.EventArgs e) {

    }

    private void objInspectors_NewInspector(Microsoft.Office.Interop.Outlook.Inspector Inspector){
       AddCustomUI();
    }

    private void AddCustomUI(){
          //...do your add button thing or whatever here
    }

  • Wiz/dumb

    The Obligatory First Post

    • 0 Comments

    So, I bet I know what you're thinking right now...if only there were a new Microsoft employee who was an experienced developer but was new to Exchange development that would create a new blog site only a week into his employment so that I could follow his progress as he learns about developing on Exchange...and it'd be really great if that happened right before Exchange "12" comes out so that I can follow his experience through that whole thing too! 

    So? How close was I?! Well, that's what you're gonna get. I am a new Support Engineer for the DSI - Messaging & Collaboration team at Microsoft. I used to work for a Microsoft Gold Partner in Richmond, VA called TCSC (The Computer Solution Company) where I focused primarily on .NET and SharePoint development.

    I don't have a ton of experience developing for Exchange & Outlook, but I thought it would be cool to share my experiences with you so you can learn with me. Hopefully, over time this will become a good resource for people trying to get into Exchange development.

     

     

Page 14 of 14 (70 items) «1011121314