Broken Exchange Schema - WebDAV allprops, sinks and/or exoledb fail to return properties
Not getting all the properties you would expect from an WebDAV ALLPROPS or from an Event sink? Well, it could be that the Exchange schema is broken.
The Problem:
If you find that your application is no longer retrieving a full list of properties, it may be due to a broken Exchange Web Store Schema.
Cause:
This is a state where the schema is broken, and can happen due to a variety of causes; such as failed extension of the schema from an application installation or incorrect schema modification of the schema. When the Exchange server has this problem, WebDAV and event sinks will not be able to get a dynamic list of properties. This will cause applications written to use these to fail to work properly. An example of this would be applications that dynamically search a folder’s contents for a message property.
Symptoms:
Any of the following symptoms may be an indication of a broken schema.
· Unable to retrieve a list of properties with a WebDAV PROPFIND using ALLPROPS.
· Unable to retrieve a list of properties with a WebDAV SEARCH without specifying each one.
· Unable to retrieve a list of all properties without specifying each one in an event sink.
· Fewer than 401 entries in the schema folder.
· The properties set on the items in the schema folder do not match those found on another server of the same version.
Checking the Schema:
The schema is viewed using Exchange Explorer, or using an API such as WebDAV or Exoledb:
Accessing Data Using the ##SCHEMAURI## Macro
https://msdn.microsoft.com/en-us/library/aa493872(EXCHG.80).aspx
Understanding EXOLEDB Default Folders
https://technet.microsoft.com/en-us/library/aa996197(EXCHG.65).aspx
Exchange Explorer
https://msdn.microsoft.com/en-us/library/aa486235(EXCHG.65).aspx
Exchange SDK Development Tools
Note that if the schema is very badly damaged, Exchange Explorer may only be able to list the entries with few of the properties. It’s also possible that the schema folder may be empty, have a low number of items or have odd values set on item properties.
Resolving the Problem:
Below are some possible ways to resolve this issue. Please review each one prior to deciding on a path forward.
Option #1 – Reset the Schema:
If your server has this problem, we have a fix to reset the schema, which is hinted at in TechNet:
Understanding EXOLEDB Default Folders
https://technet.microsoft.com/en-us/library/aa996197(EXCHG.65).aspx
NOTE: Resetting the schema will likely break the applications that are relying on the schema and will probably need to be reinstalled.
To find out if you have an application that has extended the schema, you can check the contents of the schema folder, by default there should be 401 entries. If you have less, the schema is broken. If you have more, then your schema has most likely been extended by an application. If a schema was modified by an application and is reset, then those modifications need to be redone – this is often accomplished by reinstalling the application. Be sure to follow-up with your application provider(s) prior to resetting the Exchange Web Store Schema.
You can reset the schema on an Exchange database by doing the following:
1. Determine the GUID of the database using AdsiEdit (probably going to have to hash this out)
2. Go to HKLM\System\CurrentControlSet\MSExchangeIS\Schema.
Note: this setting may be under HKLM\System\CurrentControlSet\MSExchangeIS\Parameters\Schema\<MDBGUID> on some versions of Exchange.
3. Set the GUID dword value to 0 and restart.
Congratulations, you are now running on a refreshed schema for your database.
Option #2 – Replicate the schema from a server which works to the broken one.
If you have one node which has a working schema and one which does not, then you may try to fix the problem by replicating the data from the good node back to the broken one. This may be more helpful than the reset key if the schema has been extended and you don’t want to do a reinstall.
Option #3 – Work around the issue by changing your code.
For production application development, its best to retrieve a list of properties by explicitly requesting each one rather than going off the dynamic list of properties – such as is returned using an WebDAV PROPFIND with ALLPROPs. Doing so will work around the program from a development standpoint. Retrieving a list of dynamic list of properties should only be done for exploration of which properties might be set on an item. In fact, these dynamic lists of properties do not in many/most cases return all properties. Also, retrieving properties dynamically is very time and resource expensive compared to explicitly requesting specific properties. Because of these reasons and that your application will be less likely to break if there are schema issues, its best to always request a list of specific properties than go off a dynamically generated list.
Santa, I want it all - WebDAV and the full-meal-deal - allprops.
Option #4 – Create a new database and move everything over.
OK, now this is the one you may want to avoid since it involves quite a bit of work and time. You could create a new database and then move the data over to it. This will likely be the last choice for many people.