none
Outlook Form - Voting Responses Not Auto Processing If Form Contains Any Code RRS feed

  • Question

  • I have a situation where I have some Outlook forms with voting buttons (actions) whose responses are not auto processed (tracking updated) if there is any vbscript code within the form. I have the Outlook tracking options checked for:
    • Automatically process meeting requests and responses to meeting requests and polls
    • Automatically update original sent item with receipt information
    • Update tracking information then delete responses that don't contain comments
    When I ruled out these basic settings I used MFCMAPI to start troubleshooting. The property PR_Processed was ruled out as it was not present on any item in the inbox that should have been auto processed, but was not. Upon looking at the other properties I noticed one called PidLidAutoProcessState. It was here I saw any voting response from a form that contained vbscript had a value of SSonopen, while voting responses from the same form without any code had a value of SSonsniff. I thought maybe something was wrong with the coding. So, I removed all the code and just put in one commented line in the vbscript section behind the form. Just putting that comment in was enough to cause the PidLidAutoProcessState on responses to be SSonopen, while removing the comment (no code at all) caused the value to be SSonsniff. I removed all the Outlook add-ins and disabled all virus scanning with the same results to rule out those factors. I can reproduce this in Outlook 2016 (Windows 10) and Outlook 2007 (Windows 7). The Sniffer in Outlook will not auto process the response when SSonopen is the value, Thus, the item will not update the tracking until you open it. So, my question is what could be causing the PidLidAutoProcessState setting to change its value to SSonopen with something as simple as a commented line of vbscript or is there a way to manually set this value when responding with the voting? It would be interesting if anyone else could reproduce the issue and let me know. I checked both the sending and receiving mailboxes to make sure the property was the same value to rule out anything in between causing the problem. Thanks for any assistance or direction you can provide.
    Thursday, April 13, 2017 6:55 PM

Answers

  • >>what version of Exchange did you test your Outlook 2013 with?

    I have not made it work either.

    It seems you could use VSTO Add-in, would you mind migrating VBS code to VSTO, and use VSTO to implement your requirement?


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    • Marked as answer by Eric2112 Wednesday, May 3, 2017 10:37 PM
    Tuesday, April 25, 2017 2:07 AM

All replies

  • >> I removed all the Outlook add-ins and disabled all virus scanning with the same results to rule out those factors.

    Do you mean this issue happens under Outlook Forms with VBScript, and there is no other automation?

    Could you share us the detailed steps to reproduce your issue? We will try to make a test according your description.


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, April 14, 2017 5:41 AM
  • Thanks for the reply.  Yes this is dealing with custom Outlook forms with underlying VBScript behind the form.  To recreate the issue create a custom form and then create some actions (Conflict and No Conflict in our case) under the Actions tab of the form for voting purposes.  The actions have the following items set:

    • Action Name:  Conflict  (and No Conflict for the second action)
    • Form name:  IPM.Note
    • Message Class: IPM Note
    • Characteristics of the new form when responding: Do not include original message
    • Characteristics of the new form address form like a: Do not include original message
    • Show action on is checked with Menu and Toolbar selected.
    • The action will:  Send the form immediately.
    • Subject prefix:  Conflict  (and No Conflict for the second action)

    Then put some VBScript behind the form.  The code can be anything as I put one simple commented line behind the form and could reproduce the issue.  The forms usually have a couple 100 lines of code behind them, but I took this all out and put a simple line that said  ''Test    behind the form to rule out any of the logic causing it.   I published the form to the organizational forms library in Exchange 2010, opened the form up with Outlook 2016 on a Windows 10 pc and then sent it to a test recipient with Outlook 2016 on a Windows 10 pc.  The recipient opens the form and then chooses either the Conflict or No Conflict voting button.  If you then run MFCMAPI and open up the response just sent in the Sent Items the property PidLidAutoProcessState will have a value of SSonopen, which means the Outlook sniffer will not auto process the response upon arrival.  The person will have to open the response manually to process it in the tracking.  It should have the same value in the PidLidAutoProcessState property when the voting response is received in the Inbox 

    If you reproduce the exact same steps only this time making sure there is no VBScript behind the form before publishing it to the organizational forms library (no characters of any kind - spaces, comments ....), the PidLidAutoProcessState value will be SSonSniff when you look at the response in the Sent Items with MFCMAPI.  The SSonsniff value should allow it to process automatically in the tracking when the response is received.  We are using Exchange Cache Mode, but can duplicate problem when testing this scenario without using Exchange Cache Mode.  I also clear out all of the forms cache each time to rule that out as well and have disabled all Com Add-ins and virus detection software.  Both sending and receiving pcs have the three bullet items in the original post set in their Outlook.  For testing we have Enable All Macros selected in the Trust Center Settings along with Apply Macro Security Settings to installed add-ins. 

    If you can reproduce the problem my question would be why would something as simple as a commented line of code behind an Outlook form that does nothing cause the PidLidAutoProcessState to change and is there a way to change this MAPI canonical property with VBScript?  If I missed any steps in how to reproduce the issue let me know and I will do my best to further describe it. 

    Friday, April 14, 2017 9:51 PM
  • >>If you then run MFCMAPI and open up the response just sent in the Sent Items the propertyPidLidAutoProcessState will have a value of SSonopen

    Could you share me how to run MFCMAPI and check the response step by step? I have created the custom form.


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, April 17, 2017 9:50 AM
  • You can download MFCMapi from mfcmapi.codeplex dot com   .  Microsoft's own tech documents link to this site.  So, the download should be safe.  Once installed open it up and perform the following steps on both the sending a receiving pcs:

    • From pc that responded to the Outlook Custom Form and clicked the voting option, open MFCMapi and from the menu click the Session heading and then choose Logon. 
    • Choose the profile name if prompted and click ok. 
    • Double click on the mailbox you are using to test. 
    • Expand the Root-mailbox (should be an arrow to click)
    • Expand the IPM_Subtree (should be another arrow to click)
    • Then double click the Sent Items Folder for the pc that is clicking on the voting response.
    • A screen should open with all the items in your Sent folder
    • You can then highlight the response item in your Sent Items and your should see the PidLidAutoProcessState on the split screen below.  The value will be towards the bottom.  You can also just double click on the message itself and a window will open with all of the values if you prefer that view over a split screen. 
    • If there is any kind of vbscript under the Original Form that was created, the value for me ends up being ssOnOpen for the PidLidAutoProcessState property in the Sent Items.  If the Original Form with the voting options has no vbscript underneath it the PidLidAutoProcessState property on the response ends up being ssOnSniff. 
    • On the pc that receives the answer to the voting response, do all the same steps except check the inbox or deleted items (if the value is ssOnSniff it may go to your deleted items right away).  The value for PidLidAutoProcessState should be the same as the other machine. 

    Also, I always clear out the Outlook Forms cache between testing at %userprofile%\AppData\Local\Microsoft\FORMS to rule out any cache issues.  If I missed a step in my directions or you need further clarification on any of the steps, just let me know and I will do my best to help answer.  Thanks again for taking the time to test this and I am curious to find out your results.

    Monday, April 17, 2017 5:00 PM
  • Thanks for detailed information.

    I could reproduce your issue under Outlook 2013.

    Could you share us what do you want to do with PidLidAutoProcessState? We will try to check whether there is any workaround for you.


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, April 18, 2017 9:02 AM
  • Thanks for testing this out and verifying the issue is just not with our system.  The PidLidAutoProcessState needs to be SSonsniff when responding to a voting button when there is code behind the form instead of SSonopen.  Otherwise, the voting response has to be opened manually on the receiving end for the tracking to auto update.  So, is there a way to access the PidLidAutoProcessState value with VBScript behind the Outlook form and change it to SSonsniff?  Is there some setting in Outlook, Exchange or Windows that can force this value to be SSonsniff when clicking a voting option from a form with VBScript behind it?  I have not been able to find a workaround as of yet, but any help or input would be greatly appreciated.  I am still puzzled why a commented out line of code behind a custom form with voting options could cause this value to be SSonopen instead of SSonsniff when responding.
    Tuesday, April 18, 2017 5:43 PM
  • >> So, is there a way to access the PidLidAutoProcessState value with VBScript behind the Outlook form and change it to SSonsniff?

    For this, I suggest you try PropertyAccessor, here is a simple code in VBA, I suggest you try to convert it to VBS.
    Set oMail = myFolder.Items(1)
     For Each oMail In myFolder.Items
           ‘get the mail item
            Debug.Print oMail.Subject
            'PR_TRANSPORT_MESSAGE_HEADERS
            PropName = "http://schemas.microsoft.com/mapi/id/{00062008-0000-0000-C000-000000000046}/851A0003"
            'Obtain an instance of PropertyAccessor class
            Set oPA = oMail.PropertyAccessor
            'Call GetProperty
            Header = oPA.GetProperty(PropName)
            oPA.SetProperty PropName, 1  ‘ssOnSniff is 1
            Debug.Print (Header)
            oMail.Save
     Next oMail


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, April 19, 2017 7:00 AM
  • Thanks for the coding example.  I was able to put it in VBScript, but I could never get the value to change to 1 as it would not hold.  The value would always go to 2 even when assigning it 1.  I could get it to change to 0 or 2, but not 1. I think it has something to do with the form itself being open and not being able to change to SSonsniff.  I then created a VBA add-in that will change all the items with Voting Responses to have their PidLidAutoProcessState change to 1 and initial testing appears to work because the items are not open (thus it will change to 1 and not revert to 2), but I will have to test some more tomorrow and report back.  The PropertyAccessor class is the answer to changing the value, but it doesn't appear it can be done in VBScript with the form open.  It seems something behind the scenes is preventing PidLidAutoProcessState from changing to SSonsniff while the message is open or has code behind the form.  Below is the VBScript I used and I will report back after some further testing with the VBA.  

    PropName = "http://schemas.microsoft.com/mapi/id/{00062008-0000-0000-C000-000000000046}/851A0003"

    Set fldField=Item.PropertyAccessor

    fldField.SetProperty(PropName), 1

    Item.Save




    Thursday, April 20, 2017 1:30 AM
  • If you have any update about this issue, please feel free to let us know.

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, April 21, 2017 4:41 AM
  • I got side tracked yesterday with some unexpected issues, but should be able to finish testing today.  I will post what I find in my testing.  Also, do you know what version/update of Exchange you are using on the backend?
    Friday, April 21, 2017 1:21 PM
  • The VSTO add-in can get all the voting responses and change the PidLidAutoProcessState to SSonsniff using PropertyAccessor, but the tracking doesn't update immediately in the Sent Items.  You have to let the response sit in the inbox for a minute or so without opening the item, before the tracking will update even when the value has been changed to SSonsniff.  If you move the response too soon it doesn't update the tracking.  The other option is have the code display the item and then close it to force the tracking to update, which wouldn't be a problem if there were only a handful of responses, but we have 250 voting responses to some of these forms and it takes forever to process this way.  So, is there a way I can force the Outlook Sniffer with code to recheck the PidLidAutoProcessState once I have changed the value to SSonsniff for the voting responses?  Let me know if you have any other suggestions for getting the SSonsniff items to process once they are changed.

    Saturday, April 22, 2017 12:03 AM
  • Which event did you use to set SSonsniff? Did you try Unload event?

    Have you saved the item after setting SSonsniff in VSTO Add-in? 


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.


    Monday, April 24, 2017 3:24 AM
  • I tried to set it on the Send, Close and Custom Action events behind the form in VBScript.  It will not hold the value onPidLidAutoProcessState and will revert to a value of 2.  I did not see an Unload event for a form in the Event Handler.  If it does exist let me know and I will try that.  I have also tried putting code in "This Outlook Session" on the olInboxItems_ItemAdd subroutine as well on the pc receiving the voting response, which will hold the value of 1, but will not auto process right away.  You have to let it sit there for awhile before the item will be auto processed by the sniffer, which is a problem if we have 250 responses.  Regarding the VSTO Add-in, we are saving the item in the code and it will save to a value of 1, but it will not be processed by the sniffer right away again and you have to let it sit there for a couple of minutes.   Also, what version of Exchange did you test your Outlook 2013 with?
    • Edited by Eric2112 Monday, April 24, 2017 10:34 PM
    Monday, April 24, 2017 7:19 PM
  • >>what version of Exchange did you test your Outlook 2013 with?

    I have not made it work either.

    It seems you could use VSTO Add-in, would you mind migrating VBS code to VSTO, and use VSTO to implement your requirement?


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    • Marked as answer by Eric2112 Wednesday, May 3, 2017 10:37 PM
    Tuesday, April 25, 2017 2:07 AM
  • I already attempted this previously with the VSTO and the PidLidAutoProcessState will change to 1, but it will not update the tracking unless you let the message sit there in your inbox for a couple of minutes and then the item doesn't auto delete even if you have that checked in your Outlook options.  If I could get the sniffer to run right after it is set to 1, I could get this to work, but I don't know if it is even possible to force the sniffer via code.  I have seen some posts about Lid_Is_Silent in the header being false and causing the tracking not to auto process, but that was with Exchange 2007 and we are on exchange 2010 SP3.  What version of Exchange with Outlook 2013 did you do your test with?
    Tuesday, April 25, 2017 5:33 PM
  • The version of Outlook in my previous reply is wrong, I tested it under Outlook 2016 with Exchange 15.1.1061.13.

    >>I already attempted this previously with the VSTO and the PidLidAutoProcessState will change to 1

    What I mean is empty VBS in Outlook Form. Your current issue only exists when you have VBS in Outlook Form, I suggest you try to implement the same function in VSTO which is implemented by VBS.


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, April 26, 2017 2:25 AM
  • Before I attempt to convert it to a VSTO, I opened a support ticket with Microsoft and they were able to reproduce the issue. I am waiting to hear back from them on why PidLidAutoProcessState becomes 2 when there is code behind the form and therefore the tracking does not auto process.  I will post what they have to report back once I hear from them as this appears to be a software bug.  As far as converting to a VSTO, I have script running on the custom action voting responses behind the form to route it a certain way.  If I move them to a VSTO I believe I would have to tap into the olSentItems_ItemAdd in  ThisOutlookSession to get it to work the same way if just using scripting behind the form? 
    Wednesday, April 26, 2017 8:58 PM
  • In my ticket with Microsoft, they confirmed they could reproduce the issue.  They indicated the PidLidAutoProcessState was hardcoded a 2 (SSonopen) value when there is VB script behind the form as it can cause a security warning on the receiver's end.  I indicated that would make sense if the voting response had code in it, but it does not.  The response is just a standard IPM.Note message class with no code in it.  Thus, the voting response is the same no matter whether you reply from a form with or without code underneath it and there would be no security warning either way.  They agreed with my analysis and this issue is being brought up with the Product Group at Microsoft that handles Outlook to see if they are going to consider making a change for this.  In the meantime, the only thing I can do is attempt to convert everything to a VSTO.  If they indicate they will make a product change for this I will post back here.  Thanks Edward Z for your help with this and I will mark your answer for converting this to a VSTO as the answer for now.
    Wednesday, May 3, 2017 10:37 PM