Recently I came across an issue that was new to me. I don’t have a lot of experience working with Outlook forms because I’ve always been in the infrastructure world and frankly never had a need or admittedly a desire to design any forms.
Anyway, to my point, a user came to me and wanted to know why the nice form he created for the data stored in a public folder was not displaying properly. The content was based on the contacts message class and the user had created a nice form and assigned it to the public folder, so anyone creating or opening data from that folder would see the form. He showed me what was happening (or not in this instance) and sure enough, each item he opened displayed in the standard contact form.
So I silently scratched my head and said I would look into it for him. I proceeded to research the issue and tried to get creative with my Google searches in hopes of finding some matches of other users having the same issue. It was a laborious process and information pertinent to the issue was hard to find. I looked at every aspect I could stemming from things that might be going on the Exchange server to something at the client level. I looked into the EFORMS Registry system folder,
I finally came across a KB article (MS KB 290659) with a few words which sparked my curiousity and looked like it was what I was looking for:
"A property of the item called message class determines the form the item uses. You cannot change the message class of an item manually. However, you can write Visual Basic Scripting Edition (VBScript) or Visual Basic Automation code to change the message class for all items in a folder.
When you create and publish a custom form, the form is assigned a message class. This message class determines which form is associated with an item. The format of the name is "IPM.FormType.FormName", where FormType is the type of form (Contact, Task, and such) and FormName is the name of the custom form. For example, if you create a new contact form, name it Revised, and then publish it to your Contacts folder, the message class is IPM.Contact.Revised."
Okay, so I had a little more information which might point me to the problem but I still didn’t know what the problem was. I needed some way to find out if what I just read fit our situation.
MS offered three options to resolve the issue. Being a VBScripting fan, I opted for that process. MS provides a simple, yet powerful little script to change en masse your message classes on whatever folder you point it at. Of course I wasn’t looking for that yet. I wanted to report on my findings first, then if that confirmed what I thought was the problem we could move on and actually change the classes.
So I took the base code MS provided and tweaked it a bit to first report on the existing message classes and then I would use the same code to make the changes. Here’s the script I used to spit out the current message classes to a simple text file so I could review them in Excel.
Sub Item_Open
Dim objFSO, objFile, wrongClass
Const ForWriting = 2
Const ForAppending = 8wrongClass=0‘ Create log file
‘ You may change the name and path of this log file in the following line
LogFile = "C:get-message-class.log"
Set objFSO = CreateObject("Scripting.FileSystemObject")
If objFSO.FileExists(LogFile) Then
Set objFile = objFSO.OpenTextFile(LogFile, ForAppending)
objfile.WriteLine
objFile.Writeline "Beginning message class reporting session " & Now
objFile.Writeline "Item #" & vbtab & "Description" & vbtab & "Message Class"
Else
Set objFile = objFSO.CreateTextFile(LogFile)
objFile.Close
Set objFile = objFSO.OpenTextFile(LogFile, ForWriting)
objfile.Writeline "Beginning message class reporting session " & Now
objFile.Writeline "Item #" & vbtab & "Description" & vbtab & "Message Class"
End If‘ Change the following line to your new Message Class
NewMC = "IPM.Contact.Test"Set CurFolder = Application.ActiveExplorer.CurrentFolder
Set AllItems = CurFolder.Items
NumItems = CurFolder.Items.Count‘ Loop through all of the items in the folder
For I = 1 to NumItemsSet CurItem = AllItems.Item(I)objFile.writeline I & vbtab & CurItem & vbtab & CurItem.MessageClass‘ Test to see if the Message Class needs to be changed
If CurItem.MessageClass <> NewMC Then
‘MsgBox "Item: " & CurItem & vbtab & "Current message class: " & CurItem.MessageClass
wrongClass=wrongClass+1‘ Change the Message Class
‘CurItem.MessageClass = NewMC‘ Save the changed item
‘CurItem.SaveEnd IfNextMsgBox "Done."objFile.writeline "Number of items with correct message class: " & NumItems – wrongClass
objFile.writeline "Number of items with incorrect message class: " & wrongClass
objFile.writeline "Ending message class reporting session " & Now
objFile.close
wrongClass=0
End Sub
One of the things I added was the output file )get-message-class.log) because I wanted a report I could show the user the message classes first. I also had to remark out the lines that actually make the change (CurItem.MessageClass=NewMC and CurItem.Save). I also remarked out the first MsgBox line which would have resulted in hundreds of dialog box popups. This may be fine for a few objects but can be very annoying and time consuming clicking OK every two seconds.
The name of our form was IPM.Contact.Test which was a simple form based on the Contact form template. Basically this script is designed to read all of the items in a public folder and report on the message class of each item and count the number of items that match and don’t match our form.
So, following the steps MS described I ran this in my lab with some test data and got my nice little report clearly showing which items were not set correctly. I then ran this report for the client and showed him that about 15 of the 300 entries had the wrong message classification. To fix the issue we just removed the comments from the two CurItem lines listed above and re-ran the script. Voila! Now the user was able to view the existing data in his custom form again.
Now the million dollar answer is how did they get that way if he assigned the form to the public folder? Unfortunately we don’t really know. It could have been something at the client or server level preventing the correct form from being read when creating new entries. The form could have been unlinked from the public folder for a period of time too. The bottom line is that we were able to report on and fix the issue and make the customer happy.
