Thanks for a bug report. This is slightly different from the Red Hat bug (mentioned in the See Also section). Here, you point to the Mail part, while there you point to Tasks. These are two different parts in evolution and Categories as such are not the same as Labels for mails. They are not even shared.

Mail part as such has some mapping from standard Exchange categories to built-in Evolution Labels. It's here:
https://git.gnome.org/browse/evolution-ews/tree/src/camel/camel-ews-utils.c?h=gnome-3-22#n383

It stores other categories too, but if they are not entered in the Evolution, then they are not recognized. Evolution 3.22.x doesn't have it, but 3.24.x has a Labels tab in folder properties (shown in the context menu of a folder when right-clicked above it in the folder tree on the left of the Mail view), where users can see all recognized labels as provided by the server and merge those needed into the evolution.

You can see what labels/categories had been returned by the server when you run from a terminal:

   $ sqlite3 ~/.cache/evolution/mail/<ews-account-uid>/folders.db \
     "select distinct labels from inbox where labels not null order by labels"

Where you replace <ews-account-uid> with actual folder. If in doubt, it's the one which also contains folder-tree file. The command searches for understood labels in the Inbox folder. You can then enter them into Evolution in Edit->Preferences->Mail Preferences->Labels.

I noticed that the server doesn't replace spaces in the names, which makes sense, but it also breaks logic of the code in evolution. I'll fix it (it's also partly related to this bug report).

(In reply to Milan Crha from comment #1)
> I noticed that the server doesn't replace spaces in the names, which makes
> sense, but it also breaks logic of the code in evolution. I'll fix it (it's
> also partly related to this bug report).

This [1] commit fixes the issue with spaces for 3.27.1+ and a the same landed
for 3.26.1+ too.

[1] https://git.gnome.org/browse/evolution-ews/commit/?id=932c225

Thanks for the detailed analysis. Sorry for conflating the Microsoft Exchange Categories as applied to Mail and Tasks items. For Microsoft Exchange, I believe that there is a single set of Categories and that those can then be assigned to at least Mail, Calendar, and Task items. When I run the query:

   $ sqlite3 ~/.cache/evolution/mail/<ews-account-uid>/folders.db \
     "select distinct labels from inbox where labels not null order by labels"

I do see that the Categories are coming over. It may just be an artifact of the sqlite3 query render, but I did notice that items having multiple Categories assigned are just white space separated rather than comma or otherwise delimited.

Thanks for the quick fix on the white space escaping.

I will manually enter the labels into Evolution as per Comment 1 for Evolution 3.22.x and look forward to upgrading to 3.24.x for the merge feature.

(In reply to Don Pellegrino from comment #3)
> I did notice that items having multiple  Categories assigned are just white
> space separated rather than comma or otherwise delimited.

Yes, spaces are problem, hence the fix to escape them. Evolution doesn't support spaces in Labels.

> I will manually enter the labels into Evolution as per Comment 1 for
> Evolution 3.22.x and look forward to upgrading to 3.24.x for the merge
> feature.

The 3.24.x will not contain the space-escaping change, thus you'll see the flags separated by space in the folder Properties, which is wrong (thus instead of
single entry "my category" it'll show two separate labels "my" and "category").

As per Comment 1, I manually entered the Categories from Microsoft Exchange as Mail Labels in Evolution. For the case of Microsoft Exchange Categories not having a white space in them, I was expecting the Microsoft Exchange Categories to now appear as Labels in Evolution. Perhaps I misunderstood Comment 1. Is there an additional action I need to take for the mapping to take effect in Evolution 3.22.x?

Those "not having whitespace" are recognized automatically. You can add a Labels column to the view, to see what is recognized and what isn't [1]. The tags are compared case sensitively. You can see what tag the evolution uses when you run this command:

    $ gsettings get org.gnome.evolution.mail labels 

where the text after the pipe '|' is the tag being used in the comparison, like here:

   '_Work:#ffffaa8c03f0|$Labelwork'

the UI shows 'Work', but the internal Label tag is '$Labelwork'.

[1] https://help.gnome.org/users/evolution/stable/mail-change-columns-in-message-list.html.en

There had been filled https://gitlab.gnome.org/GNOME/evolution-ews/issues/24 recently, thus I'm closing this bug in favor of the new bug.