• Wiz/dumb

    CDO Workflow Designer Troubleshooting


    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


    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)

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


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

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

  • Wiz/dumb

    The Obligatory First Post


    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 1 of 1 (3 items)